On Mon, 17 Jun 2024 13:42:20 +0200 Gerd Hoffmann kraxel@redhat.com wrote:
On Fri, Jun 14, 2024 at 01:05:44PM GMT, Kevin O'Connor wrote:
On Fri, Jun 14, 2024 at 12:54:28PM +0200, Gerd Hoffmann wrote:
Hi,
Be a bit more conservative, and only enable the window by default when the ram size extends beyond 60G. Due to the mmio window this translates to an effective working configuration limit of 58G/59G, depending on machine type.
Why 60GB not 64GB?
Could this change introduce a further regression - guests with 32GB of ram that need extra pci space now break?
Unlikely.
If ram size is not a good indicator of being 64bit capable, are there other indicators that we could use (eg, looking for how much memory the PCI devices are requesting)?
If the pci bars of coldplugged devices do not fit into the 32-bit mmio window below 4G seabios will enable the 64-bit mmio window too.
Turning on the 64-bit mmio window in more cases is indented to make hotplugging devices with large pci bars easier.
So the only case where a regression could happen is if hotplugging is involved, for example a 32G guest gets a device with a 4G pci bar hotplugged. This can be handled by manually setting up pci(e) bridge window size hints in qemu. Same way this case would have been handled before commit 96a8d130a8c2 ("be less conservative with the 64bit pci io window").
we had a number of hotplug related issues due to insufficient MMIO window size, especially when it comes to linux guests. Until 96a8d130a8c2 made those complains go away in most cases. So it would 'regress' those cases. Also I'd say RAM size is not a good indicator that guest doesn't need/can't handle 64-bit MMIO window, it's totally valid config to have low RAM guest with devices that have large PCI bars.
While it's possible to tweak MMIO windows size on QEMU CLI, it's inconvenient and that cascades over to upper layers (libvirt, whatnot on top of that) eventually ending up at end-user somewhere if that config change supported.
So this patch would 'break' pci hotplug on modern linux guest which could or couldn't be fixed by enduser (depending on used sw stack).
Is there any other way to fix old 32 linux guest issues while keeping modern ones happy as well?
take care, Gerd
SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-leave@seabios.org