qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Default for phys-addr-bits? (was Re: [PATCH 4/5] x86: A


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] Default for phys-addr-bits? (was Re: [PATCH 4/5] x86: Allow physical address bits to be set)
Date: Wed, 29 Jun 2016 17:42:53 +0100
User-agent: Mutt/1.6.1 (2016-04-27)

* Gerd Hoffmann (address@hidden) wrote:
>   Hi,
> 
> > > Well the crash of guest phys bits > host phys bits, should be easy to
> > > reproduce by booting a 65GB guest on a 64GB RAM + 2GB swap host with
> > > 36 host phys bits using the upstream qemu that forces the guest phys
> > > bits to 40.
> > 
> > So you supply more RAM than host can address, and guest crashes?
> 
> Yep.  The only reason we don't see this happening in practice is that
> it's probably next to impossible to find a machine which has (a) only 36
> physical address lines and (b) allows to plug that much RAM.
> 
> > Why are we worried about it?
> 
> It's more a issue with pci ressources.  In theory seabios/edk2 could go
> figure how big the physical address space is, then map 64bit pci bars as
> high as possible, thereby making stuff like etc/reserved-memory-end in
> fw_cfg unnecessary.
> 
> But with qemu saying 40 phys bits are available even if they are not
> this approach isn't going to fly ...

Something somewhere in qemu/ kernel/ firmware is already reading the number
of physical bits to determine PCI mapping; if I do:

./x86_64-softmmu/qemu-system-x86_64 -machine q35,accel=kvm,usb=off -m 
4096,slots=16,maxmem=128T   -vga none -device 
qxl-vga,bus=pcie.0,ram_size_mb=2048,vram64_size_mb=2048 -vnc 0.0.0.0:0 
/home/vms/7.2a.qcow2 -chardev stdio,mux=on,id=mon -mon 
chardev=mon,mode=readline -cpu host,phys-bits=48

it will happily map the qxl VRAM right up high, but if I lower
the phys-bits down to 46 it won't.

    VGA controller: PCI device 1b36:0100
      IRQ 11.
      BAR0: 32 bit memory at 0xc0000000 [0xdfffffff].
      BAR1: 32 bit memory at 0xe0000000 [0xe3ffffff].
      BAR2: 32 bit memory at 0xe4070000 [0xe4071fff].
      BAR3: I/O at 0xc080 [0xc09f].
      BAR4: 64 bit prefetchable memory at 0x800480000000 [0x8004ffffffff].
      BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
      id ""

I'll admit to not understanding why it all still boots and doesn't
fall in a mess with that mapping (46 bit Xeon).

Dave
> 
> cheers,
>   Gerd
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]