Hi Gerd,
On 5/29/19 8:01 AM, Gerd Hoffmann wrote:
On Wed, May 29, 2019 at 07:48:03AM +0300, Marcel Apfelbaum wrote:
Hi Gerd,
On 5/28/19 11:43 PM, Gerd Hoffmann wrote:
This patch changes the handling of the mmconfig area. Thanks to the
pci(e) expander devices we already have the logic to exclude address
ranges from PCI0._CRS. We can simply add the mmconfig address range
to the list get it excluded as well.
With that in place we can go with a fixed pci hole which covers the
whole area from the end of (low) ram to the ioapic.
This will make the whole logic alot less fragile. No matter where the
firmware places the mmconfig xbar, things should work correctly. The
guest also gets a bit more PCI address space (seabios boot):
# cat /proc/iomem
[ ... ]
7ffdd000-7fffffff : reserved
80000000-afffffff : PCI Bus 0000:00 <<-- this is new
b0000000-bfffffff : PCI MMCONFIG 0000 [bus 00-ff]
b0000000-bfffffff : reserved
c0000000-febfffff : PCI Bus 0000:00
f8000000-fbffffff : 0000:00:01.0
[ ... ]
So this is a guest visible change.
Looks good to me, but shouldn't we use some compat
property to not affect previous machine versions?
acpi table changes are typically not versioned, and IIRC the acpi tables
are part of the live migration data stream so the tables will not change
under the feet of the running guest even when it is migrated to another
qemu version.
I wasn't "worried" only about migration, but also about the visible
change in
the guests keeping the same machine type and upgrading QEMU.
I am not saying is a "big" issue since it will probably not affect the
guests at all.
Upgrading QEMU will look like a firmware update or something.
Thanks,
Marcel
cheers,
Gerd
