On 06/17/16 11:52, Igor Mammedov wrote:
On Fri, 17 Jun 2016 11:17:54 +0200
Gerd Hoffmann <address@hidden> wrote:
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
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
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.
currently firmware would assign 64-bit BARs after reserved-memory-end
(not sure about ovmf though)
OVMF does the same as well. It makes sure that the 64-bit PCI MMIO
aperture is located above "etc/reserved-memory-end", if the latter exists.
but QEMU on ACPI side will add 64-bit _CRS only
for firmware mapped devices (i.e. no space reserved for hotplug).
And is I recall correctly ovmf won't map BARs if it doesn't have
a driver for it
Yes, that's correct, generally for all UEFI firmware.
More precisely, BARs will be allocated and programmed, but the MMIO
space decoding bit will not be set (permanently) in the device's command
register, if there is no matching driver in the firmware (or in the
device's own oprom).
so ACPI tables won't even have a space for not mapped
This used to be true, but that's not the case since
Namely, specifically for conforming to QEMU's ACPI generator, OVMF
*temporarily* enables, as a platform quirk, all PCI devices present in
the system, before triggering QEMU to generate the ACPI payload.
Thus, nowadays 64-bit BARs work fine with OVMF, both for virtio-modern
devices, and assigned physical devices. (This is very easy to test,
because, unlike SeaBIOS, the edk2 stuff built into OVMF prefers to
allocate 64-bit BARs outside of the 32-bit address space.)
Devices behind PXBs are a different story, but Marcel's been looking
into that, see <https://bugzilla.redhat.com/show_bug.cgi?id=1323976>.
There was another attempt to reserve more space in _CRS
That's actually Marcel's first own patch set for addressing RHBZ#1323976
that I mentioned above (see it linked in
It might have wider effects, but it is entirely motivated, to my
knowledge, by PXB. If you don't have extra root bridges, and/or you plug
all your devices with 64-bit MMIO BARs into the "main" (default) root
bridge, then (I believe) that patch set is not supposed to make any
difference. (I could be wrong, it's been a while since I looked at