Am 16.07.24 um 17:15 schrieb Igor Mammedov: > On Tue, 16 Jul 2024 15:58:35 +0200 > Fiona Ebner <f.eb...@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.eb...@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.eb...@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 _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
