linux-user/i386/cpu_loop.c | 57 ++++++++++---------- target/i386/cpu.c | 103 +++++++++++++++++++++++++++++++++--- target/i386/tcg/translate.c | 6 ++- 3 files changed, 126 insertions(+), 40 deletions(-)
When running qemu-i386 even with -cpu Nehalem (aka x86_64-v2), it raises the warning TCG doesn't support requested feature: CPUID.80000001H:EDX.lm [bit 29] Likewise using qemu-x86_64 with -cpu Haswell, it raises warnings for TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] Even though x86_64-v3 is the level that qemu-user is supposed to provide. These are two related problems: - for Haswell, the 4 missing features are only relevant to code running in kernel mode; we can ignore them and mark them as supported even though they are not. The supported features are only used to print the warnings - 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. Other CPU models have warnings for the ARCH_CAPABILITIES MSR; hide them as well in a similar manner. Based-on: <20230623131711.96775-1-pbonzini@redhat.com> Paolo Bonzini (3): target/i386: ignore ARCH_CAPABILITIES features in user mode emulation target/i386: ignore CPL0-specific features in user mode emulation target/i386: emulate 64-bit ring 0 for linux-user if LM feature is set linux-user/i386/cpu_loop.c | 57 ++++++++++---------- target/i386/cpu.c | 103 +++++++++++++++++++++++++++++++++--- target/i386/tcg/translate.c | 6 ++- 3 files changed, 126 insertions(+), 40 deletions(-) -- 2.41.0
On Mon, Jun 26, 2023 at 10:33:14AM +0200, Paolo Bonzini wrote: > When running qemu-i386 even with -cpu Nehalem (aka x86_64-v2), it raises the > warning > > TCG doesn't support requested feature: CPUID.80000001H:EDX.lm [bit 29] > > Likewise using qemu-x86_64 with -cpu Haswell, it raises warnings for > > TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] > TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] > TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] > TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] > > Even though x86_64-v3 is the level that qemu-user is supposed to provide. > These are two related problems: > > - for Haswell, the 4 missing features are only relevant to code running > in kernel mode; we can ignore them and mark them as supported even > though they are not. The supported features are only used to print > the warnings > > - 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'. 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 :|
On Mon, Jun 26, 2023 at 11:20 AM Daniel P. Berrangé <berrange@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
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é <berrange@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 :|
On Mon, Jun 26, 2023 at 11:36 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > > > 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. By the way it's possible that the above comment would not be true anymore with the "one binary" work that is going on (though I'm not sure if that applies to system emulation only). However, the effect on speed for 32-bit hosts remains true until we ditch them altogether. Paolo
On 6/26/23 11:37, Paolo Bonzini wrote: > On Mon, Jun 26, 2023 at 11:36 AM Daniel P. Berrangé <berrange@redhat.com> wrote: >>>> 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. > > By the way it's possible that the above comment would not be true > anymore with the "one binary" work that is going on (though I'm not > sure if that applies to system emulation only). However, the effect on > speed for 32-bit hosts remains true until we ditch them altogether. Yes, one binary work is system-mode only. Primarily because of the ABI issues you describe. r~
© 2016 - 2024 Red Hat, Inc.