https://bugs.kde.org/show_bug.cgi?id=374596
Philippe Waroquiers <philippe.waroqui...@skynet.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |philippe.waroquiers@skynet. | |be --- Comment #10 from Philippe Waroquiers <philippe.waroqui...@skynet.be> --- I guess that the problem is because VEX (somewhat) examines the cpu it is running on, to advertise to the guest program another model of cpu, chosen in a limited nr of predefined models : see guest_amd64_toIR.c handling of the CPUID instruction. I am however wondering what VEX advertises on this qemu cpu. According to the VEX code, in your case, it should advertise a basic cpu that has no RDTSCP. Can you run valgrind --trace-flags=10000000 --trace-notbelow=1 --tool=none cpuid|&grep -i 'dirty.*cpuid' and see what this gives ? I am also wondering if m_machine.c sets have_rdtscp to True. Can you also do: valgrind --tool=none -v -v -v -d -d -d date|&grep 'arch =' (for me, these 2 commands give: DIRTY 1:I1 MoFX-gst(16,8) WrFX-gst(40,8) MoFX-gst(24,8) WrFX-gst(32,8) ::: amd64g_dirtyhelper_CPUID_avx_and_cx16{0x3817bd10}(BBPTR) --7119:1: main ... arch = AMD64, hwcaps = amd64-cx16-lzcnt-rdtscp-sse3-avx-avx2-bmi I find the above bizarre: the reported arch has sse3/cx16/avx2 but the called dirty helper is amd64g_dirtyhelper_CPUID_avx_and_cx16, while I was expecting amd64g_dirtyhelper_CPUID_avx2 -- You are receiving this mail because: You are watching all bug changes.