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.

Reply via email to