|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Need help in debugging partially blocked hypervisor
Hi,
> I need some help in debugging a strange hypervisor behavior together
> with using fully virtualized performance counters.
>
I added some own tracer to xentrace to find, what the CPU is doing.
No I can see, that in the strange case the CPU is doing endless (and nothing
else!) performance counter NMI's within the hypervisor.
pmu_apic_interrupt
smp_pmu_apic_interrupt
vmx_do_pmu_interrupt
vpmu_do_interrupt
In the normal case in core2_vpmu_do_interrupt:
1. Read the cause of the nmi
rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, msr_content);
...
2. Save the value for the domU
...
3. Reset the cause
wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
4. Inject NMI in domU
This works very well for a short time.
Then the hypervisor falls in the endless nmi loop. The cause for this seems
to be that "3. Reset the cause" doesn't work anymore. Means writing to the
MSR_CORE_PERF_GLOBAL_OVF_CTRL doesn't reset the MSR_CORE_PERF_GLOBAL_STATUS
which leads to the next nmi immediately.
I found this by adding another tracer which reads the
MSR_CORE_PERF_GLOBAL_STATUS
once again after writing the MSR_CORE_PERF_GLOBAL_OVF_CTRL.
In the normal case this contains now 0, in the strange case the value is
unchanged!
I searched the intel processor spec but couldn't find any help.
So my questions is, what is wrong here?
Can anybody with more knowledge point me in the right direction, what can I
still
do to find the real cause of this?
Many thanks in advance!
Dietmar.
--
Company details: http://ts.fujitsu.com/imprint.html
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|