On 11/12, Igor Mammedov wrote:
!-------------------------------------------------------------------| This Message Is From an External Sender This message came from outside your organization. |-------------------------------------------------------------------!
On Tue, 12 Nov 2024 12:33:58 +0100 Gerd Hoffmann kraxel@redhat.com wrote:
On Thu, Oct 24, 2024 at 12:36:16PM +0200, Claudio Fontana wrote:
What do we lose by just reverting things to the state that actually worked?
Well, the world is moving forward, devices getting more memory and larger pci bars. GPUs can have multi-GB pci bars these days. nvidia has a NPU with a 128 GB pci bar. Note this is larger than the whole (initial) PAE address space. I want seabios supporting that kind of devices well.
The range of configurations becomes more and more wide, with huge devices as mentioned above on one end and old 32-bit guests on the other end. Have seabios automatically setup itself turned out to be a hard problem (as this thread clearly shows).
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:
(1) Tweak the heuristic. (1a) Raise the memory limit.
It seems to me that the thinking here is backwards, the change to the heuristic behavior was a regression from the standpoint of QEMU, an upgraded bios bricked existing guests. Should it not be the case that '32bit-friendly' is enabled by default, and a runtime config switch is provided to expose the expanded PCI BAR space?
If you want the new thing - supply the new flag?