On Mon, Jun 26, 2023 at 11:27:54AM +0200, Paolo Bonzini wrote: > On Mon, Jun 26, 2023 at 11:20 AM Daniel P. Berrangé <berra...@redhat.com> > wrote: > > > - for qemu-i386, the issue is that this emulator is restricted to running > > > programs on a 32-bit processor, even though it is actually emulating > > > programs that use the 32-bit kernel ABI on any processor. The behavior > > > the processor in compatibility (32-bit CS, EFER.LMA=1) mode is mostly > > > the same as when EFER.LMA=0 and the little code that is needed to handle > > > 64-bit ring-0 is even present in the qemu-i386 binary, just hidden > > > behind checks for HF_LMA_MASK. So, LM can also be treated as a feature > > > that is only relevant in kernel mode; not entirely, so this cannot yet > > > be extended to bsd-user, but the required changes are minimal. > > > > IMHO in this case we should hard block all named CPUs with > > 'lm' set from qemu-i386. It only makes sense to use named CPU > > models that were actually from the 32-bit era with qemu-i386. > > > > If someone wants Nehalem then they should be using qemu-x86_64. > > If someone wants qemu-i386 then they should be using an older > > named CPU model predating 'lm'. > > What you write is true for qemu-system-*, but the problem is that > qemu-user binaries are only able to run one ELF target. qemu-x86_64 is > not able to run i386 binaries, unlike a 64-bit kernel; and that's > really intrinsic in the design of qemu-user because implementing > multiple ABIs (including multiple definitions of structs and syscall > numbers) would require compiling the same files multiple times.
Oh, right, yes, ignore my comment. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
