Am 16.07.24 um 17:15 schrieb Igor Mammedov:
On Tue, 16 Jul 2024 15:58:35 +0200 Fiona Ebner f.ebner@proxmox.com wrote:
Am 16.07.24 um 14:48 schrieb Igor Mammedov:
On Tue, 16 Jul 2024 13:56:08 +0200 Fiona Ebner f.ebner@proxmox.com wrote:
Am 12.07.24 um 15:26 schrieb Igor Mammedov:
On Fri, 12 Jul 2024 14:24:40 +0200 Fiona Ebner f.ebner@proxmox.com wrote:
we've also had two reports about issues with 32-bit guests now[0][1] (both had '-m 4096' in the QEMU commandline), which I was able to reproduce with a 32-bit Debian 12.6 install, so nothing ancient ;) The QEMU commandline is below[2].
is it also reproducible with upstream kernel? if yes, it would be better to fix that on guest kernel side, rather than in SeaBIOS which has no idea what guest OS is going to be running after it.
Turns out it's only kernels with PAE. The 6.1 Debian kernel without PAE boots fine (but the PAE was the one installed by default). I built a 6.10 kernel and it also boots fine, a 6.10 build with PAE doesn't.
Appending 'disable-modern=on,disable-legacy=off' to the virtio-scsi-pci line made it work however (also with pc machine) :)
does it also help in Windows case?
Sorry, I haven't set it up right now. I only reproduced the issue with Debian.
Perhaps it's a better workaround (compared to lm=off or going back to older bios or dumb-ing down bios to suit PAE guests) for use on mgmt side, as it directly targets bug in guest's virtio-driver.
Can we put this config tweak into libosinfo somehow, so that provisioning tools/mgmt could all reuse that to properly configure virtio for PAE kernels?
How would you detect whether the guest kernel is PAE or not before starting QEMU?
that's what mgmt can do by poking in install media/disk image or asking user only mgmt can potentially know what target OS would be and properly configure QEMU (it's not something qemu or firmware can reasonably deal with on their own). (libosinfo can detect OS on install media, perhaps it also could be taught to probe what kernel would be used)
As Gerd have said, all we can do at firmware level is heuristics, and in this case there is no good solution, we either hurt PAE guests with buggy driver by increasing size or hurt 64-bit guests by reducing it. In both cases we would get bug reports, and I'd expect a shift in numbers from PAE reports towards large device hotplug as time goes on.
I see, thank you very much for the explanations!
Best Regards, Fiona