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. Also, when using qemu-i386 on a (non-x86) 32-bit host you really do not need the performance penalty of 64-on-32 emulation to run 32-bit binaries. Paolo
