The comments with the other reports were just in support of getting them fixed, and providing a reason as to why that matters. Someone looking at those reports may not read this one, and as the issues are symptoms of the same larger issue, this report was filed as an overarching report, as AVX is just one aspect. Depending on the CPU model picked, an entire slew of error messages are generated.
Fact is, an emulator that claims it emulates a CPU has a bug, if that CPU cannot be properly emulated. Hence this report. For the emulator not to have to be considered buggy, EITHER the CPU type has to be delisted as supported OR the missing instructions must be implemented. But it’s not proper to say QEMU can emulate an x86_64 Penryn system, when trying to do so fails miserably because of instructions unimplemented in TGC. At the very least the documentation and online help would have to distinguish between KVM-only CPU types and TGC CPU types. Downloading and compiling QEMU 5 sources and compiling them on an ARM64 platform results in qemu-system-x86_64 -cpu help listing all sorts of CPUs as „available“ even though these have significant gaps in the covered instruction set. If that’s not a bug, I don’t know. How you go about fixing it, is a different matter. You could remove the CPUs, mark them as incompletely implemented, or add support for the missing features. Maybe it might even be possible to interest intel to contribute code from their SDE project to TCG -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1884095 Title: QEMU not sufficiently focused on qEMUlation, with resulting holes in TCG emulation coverage Status in QEMU: Invalid Bug description: It seems that QEMU has stopped emphasizing the EMU part of the name, and is too much focused on virtualization. My interest is at running legacy operating systems, and as such, they must run on foreign CPU platforms. m68 on intel, intel on ARM, etc. Time doesn't stand still, and reliance on KVM and similar x86-on-x86 tricks, which allow the delegation of certain CPU features to the host CPU is going to not work going forward. If the rumored transition of Apple to ARM is going to take place, people will want to e.g. emulate for testing or legacy purposes a variety of operating systems, incl. NeXTSTEP, Windows, earlier versions of MacOS on ARM Macs. Testing that scenario, i.e. macOS on an ARM board with the lowest possible CPU capable of running modern macOS, results in these problems (and of course utter failure achieving the goal): qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000007H:EDX.invtsc [bit 8] qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] And this is emulating a lowly Penryn CPU with the required CPU flags for macOS: -cpu Penryn,vendor=GenuineIntel,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc Attempting to emulate a more feature laden intel CPU results in even more issues. I would propose that no CPU should be considered supported unless it can be fully handled by TCG on a non-native host. KVM, native-on- native etc. are nice to have, but peripheral to qEMUlation when it boils down to it. At the very least, there should be a CLEAR distinction which CPUs require KVM to be used, and which can be fully emulated. It should not require wasting an afternoon to figure out that an emulation attempt is futile because TCG lacks essential functionality. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1884095/+subscriptions
