> > 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: > > > > (1) Tweak the heuristic. > > (1a) Raise the memory limit. > > that would be improvement for legacy but worsen modern guest situation.
Well, guests having devices with huge memory bars are unlikely to have only small amounts of main memory, so I think this shouldn't be too bad. Depends a bit on the new limit chosen (when going down that route) obviously. > Perhaps we at the point where heuristic can't help anymore. Could be. > > (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. > > If I'm not wrong it's possible to assign a device with large PCI bar to 'pc' > machine. > so just machine type won't be sufficient. It's possible, sure. But having devices with multi-GB bars is a relatively recent thing (when compared to the age of the pci express 1.0 spec). I don't think many (if any) legacy pci devices with multi-GB bars exist. Placing pci express devices into a legacy pci slot of the pc machine type is possible, but it comes with a number of quirks like not being able to access all pci config space. It's one of the reasons why we added the pcie-capable q35 chipset emulation to qemu. Which why I think going by machine type would be a sensible idea. > > (1c) Other ideas? > > Perhaps a fwcfg file '32_bit_guest' passed to Seabios can serve as switch. > But given Seabios and QEMU have no clue about OS nor should they, > onus would be on management to configure qemu with compat option. Well, we have that already. The config option is "turn off long mode support". Drawback is that this way seabios can't choose the default guest setup, qemu default for long mode is enabled and it is not going to change. The other way around would make sense, i.e. have seabios default to 32-bit guest setup and switch into 64-bit guest mode with a fwcfg file (see also the reply by Max). > > (2) Add a compile-time option (CONFIG_...) to force 32-bit friendly > > setup unconditionally. > > Given that mgmt would have configure QEMU one way or another to handle > legacy guests. This option might be preferable to runtime switch. Well, a runtime switch surely is better than a compile time switch. That's why seabios checks long mode support of the cpu already. But I don't see an agreement emerging on what the default should be ... The vast majority of guests should be 64-bit these days. I think when it comes to guests officially supported on RHEL hosts there are no 32-bit OSes left these days. So defaulting to 64-bit makes sense here. For some of the providers discussing here there are apparently enough 32-bit guests still being active that requiring manual config invention to keep them working is too much of a customer support burden, even if it is only a small minority. So they would probably prefer a 32-bit default. Maybe we should have a 'guest-hint' fwcfg file, carrying either '32' or '64' as value to choose the default at runtime, and a CONFIG_DEFAULT_GUEST_HINT compile time option which decides what to do in case the fwcfg file is not present. take care, Gerd _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
