OSDev.org

Hi,

parfait wrote:So, I suspect that the MSR 0x38f does not exist or is not supported as Brendan said (weird, isn't it?).
This is the result of CPUID.x0A (in the kernel on qemu-system-x86_64 -cpu host --enable-kvm)
EAX 7300402
EBX 0
ECX 0
EDX 603
According to Intel doc, this means that the
EAX[bits 7:0] = 2 => Architectural Performance Monitoring Version is 2
But EBX = 0 => so none of architectural event is supported

That's not right (for EBX, the event is not available if the bit is 1, and the even is available if the bit is 0).

Mostly EAX[bits 31:24] says that the lowest 7 bits of EBX matter, and the lowest 7 bits of EBX are all 0 so all of those 7 events are "supported".

parfait wrote:However EDX[bits 12:5] = 0x60 (96) seems very weird to me (not to high?).
Those values make me very confuse, any explanation is welcome

That seems weird to me too (given that the RDMSR and WRMSR instructions only support 64 bits anyway).

I'd also be tempted to check if CPUID misreported the information - Intel's manual (in "18.2.2 Architectural Performance Monitoring Version 2") says:

Intel wrote:NOTE: Early generation of processors based on Intel Core microarchitecture may report in CPUID.0AH:EDX of support for version 2 but indicating incorrect information of version 2 facilities.

I was too lazy to find/check the errata list to determine what these CPUs actually report (and I don't know if KVM correctly emulates CPU flaws).


Cheers,

Brendan

parfait wrote: So, I suspect that the MSR 0x38f does not exist or is not supported as Brendan said (weird, isn't it?).

My tests were done on kernel 4.15.9-300 from Fedora running on IvyBridge i5-3330. Moreover, 0x38f is the same msr MSR_PERF_GLOBAL_CTRL from the code you pasted the first time around. Are you saying that when you posted your code that msr was supported, and now is unsupported?

parfait wrote:This is the result of CPUID.x0A (in the kernel on qemu-system-x86_64 -cpu host --enable-kvm)
EAX 7300402
EBX 0
ECX 0
EDX 603
According to Intel doc, this means that the
EAX[bits 7:0] = 2 => Architectural Performance Monitoring Version is 2
But EBX = 0 => so none of architectural event is supported
EDX[bits 4:0] = 3 => it has 3 fixed-function performance counters
However EDX[bits 12:5] = 0x60 (96) seems very weird to me (not to high?).
Those values make me very confuse, any explanation is welcome

The value seems high because of miscalculation. EDX[12:5] is 0x30.

Your CPUID(0xa) output is alright.

EAX 7300402 is:
Version ID:0x2
Counters: 0x4
GP bit width: 0x30 = 0n48
EBX vector len: 7

EBX 0 says all 7 events are AVAILABLE.
For EDX 0x603, bits [12-5] are the value 0x30 (and not 0x60 as posted).



Edit: Since 0x38f is an architectural msr, it should be available to bare-metal OS and qemu-kvm guests, running on i5-4300u.

At present, the most one can do is to confirm that the kernel (i.e. kvm) and the qemu being used are the latest available, and to enable detailed kvm traces to see if they show any errors accessing the msr.

Please run the tests with the kvm traces enabled - that will help confirm the reasons for the crashes the guest sees. If the claim that the msr 0x38f is unsupported was made after looking at the traces, please paste them here.

linuxyne wrote:

parfait wrote: So, I suspect that the MSR 0x38f does not exist or is not supported as Brendan said (weird, isn't it?).

My tests were done on kernel 4.15.9-300 from Fedora running on IvyBridge i5-3330. Moreover, 0x38f is the same msr MSR_PERF_GLOBAL_CTRL from the code you pasted the first time around. Are you saying that when you posted your code that msr was supported, and now is unsupported?

It's fine now. The problem was actually due to the value (EAX = 0xff) to be written in the PERF_GLOBAL_CTRL (MSR 0x38f).
CPUID.x0A:EAX[15:8] = 4 => we have only 4 general purposes counters, so my virtual cpu doesn't accept setting bits 7:4 of MSR 0x38f
Now the program works, it reboots well and the NMI appears in the KVM trace too. Thank you Linuxyne, this clears out a lot of doubt.
Thank you Brendan too, for your contribution.
So the problem must be on the guest side.
I will try to add an NMI (or an IRQ) handler to further verify that it does work on the guest side too (And that the NMI triggers really at counter overflow) .
I think I would need a boot-loader since all this will not fit in 512 octets.

Hello all,
After a lot of digging, I am back after haveing discovered what was wrong with my initial code to get the performance monitoring interrupt (PMI) fired on qemu-kvm.
I decided to post it here for it may help others.
To recall the problem, I was not able to catch the PMI in my guest when it runs on qemu (kvm-enabled, cpu = host) whereas it works fine on a real machine.
Linuxyne gave us a similar code that works fine both on qemu and on real machine. So I was a bit confuse; why I was not able to catch the PMI with my former code if they were similar.
After some digging, it happens that, when running on qemu, to get the PMI works, you have to set the counter's initial value (MSR_PERF_FIXED_CTR0: 0x38d) before setting the instruction counting mode (MSR_PERF_FIXED_CTRL: 0x309). Whereas on the real machine, the order does not matter (As far as I know).
Can anyone confirm this? Is this a well desired behaviour?
However, there is another problem concerning getting multiple PMIs, but I shall detail this in another thread.
Conclusion :
This code works

; set counter value.
mov edx, 0xffff
mov eax, 0xffff0000
mov ecx, 0x309
wrmsr

; set counting mode
xor edx, edx
mov eax, 0xa
mov ecx, 0x38d
wrmsr

whereas this one does not

; set counting mode
xor edx, edx
mov eax, 0xa
mov ecx, 0x38d
wrmsr

; set counter value.
mov edx, 0xffff
mov eax, 0xffff0000
mov ecx, 0x309
wrmsr

Check intel_pmu_set_msr.

It calls reprogram_fixed_counters when the msr being written to is 0x38d. However, here (msr 0x309 being written), it merely updates the counter without forcing its reprogramming.

The counter value ends up being utilized here.

Without a prior programming of 0x309, the pmc->counter value, utilized to setup the counter when 0x38d is written, is 0. That should either disable the counting, or setup a target value of 2^48 (for a counter of width 48 bits) instructions which can take a while to overflow. I do not know about the behaviour, but it can be discerned if the system can read the msr (to see if it is counting, or it is disabled), or through browsing the kernel source.

Ok, you are right,
So let's dig a bit the kernel code to see what is going on.
Thanks a lot for all these explanation, it gives a good starting point.