* Gerd Hoffmann (kra...@redhat.com) 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 / dgilb...@redhat.com / Manchester, UK
