On Tue, Nov 12, 2024 at 12:33:58PM +0100, Gerd Hoffmann wrote:
We already have a runtime config switch to force 32-bit friendly setup (turn off long mode support in the vcpu).
We already have a heuristic to select the 32-bit friendly setup, which right now is simply "no memory above 4G is present".
The options I see to move this forward:
I think there is another option:
- Revert the commits that added the pci sparse mapping heuristic (starting with commit 96a8d130) and replace with an explicit indicator from qemu when seabios should attempt to allocate sparse pci mappings. Alas, this isn't a great option as commit 96a8d130 has been around for so long that changing it now seems just as likely to create new regressions.
(1) Tweak the heuristic. (1a) Raise the memory limit.
I think this seems okay to me (or at least, least bad). If there are a large number of guests that require sparse pci mappings with low guest memory, then perhaps we could add a new "etc/pci_sparse_mapping" config option to allow users to force a different setting.
(1b) Maybe also look at other things such as the machine type. The 'pc' machine type does not support pci express, so it is highly unlikely that devices with huge pci bars will be used with it and we could use that as another hint to better select the 32-bit friendly setup.
FWIW, this doesn't sound like a great option. I fear the more heuristics we add the more likely we'll get subtle breakage.
(1c) Other ideas?
(2) Add a compile-time option (CONFIG_...) to force 32-bit friendly setup unconditionally.
FWIW, this doesn't sound like a great option. If admins don't want to force a guest to work by changing qemu options (eg, turn off long mode) then they also wont want to manually select a different SeaBIOS binary.
Cheers, -Kevin