On Mon, 17 Jun 2024 13:42:20 +0200
Gerd Hoffmann <kra...@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-le...@seabios.org
>
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
