On Fr, 2016-06-17 at 10:43 +0200, Paolo Bonzini wrote: > > On 17/06/2016 10:15, Dr. David Alan Gilbert wrote: > > Larger is a problem if the guest tries to map something to a high > > address that's not addressable. > > Right. It's not a problem for most emulated PCI devices (it would be a > problem for those that have large RAM BARs, but even our emulated video > cards do not have 64-bit RAM BARs, I think;
qxl can be configured to have one, try "-device qxl-vga,vram64_size_mb=1024" > > 2) While we have maxmem settings to tell us the top of VM RAM, do > > we have anything that tells us the top of IO space? What happens > > when we hotplug a PCI card? > (arch/x86/kernel/setup.c) but I agree that (2) is a blocker. seabios maps stuff right above ram (possibly with a hole due to alignment requirements). ovmf maps stuff into a 32G-aligned 32G hole. Which lands at 32G and therefore is addressable with 36 bits, unless you have tons of ram (> 30G) assigned to your guest. A physical host machine where you can plug in enough ram for such a configuration likely has more than 36 physical address lines too ... qemu checks where the firmware mapped 64bit bars, then adds those ranges to the root bus pci resources in the acpi tables (see /proc/iomem). > You don't know how the guest will assign PCI BAR addresses, and as you > said there's hotplug too. Not sure whenever qemu adds some extra space for hotplug to the 64bit hole and if so how it calculates the size then. But the guest os should stick to those ranges when configuring hotplugged devices. cheers, Gerd
