Dear list,
We are some researchers who are interested in Xen so much. And recently we meet
a problem when we want to fetch some Intel Last Branch Record information of
guest HVMs.
When we are trying to debug the Intel IA32_DEBUGCTL MSR on Xen 4.6.0
(specifically we set the value as 1 when every vm-exit cased by a mov-to-cr3
i.e. a context switch in an HVM machine comes), we find that the value in this
IA32_DEBUGCTL MSR became 0 again. Does anyone know what's happening there? The
problem makes us going crazy because we really want to use the LBR information
which is enabled by the last bit of the IA32_DEBUGCTL MSR, but we cannot find
where the key code makes the bit flip to zero again.
BTW, to get the some useful information from LBR, we first disabled EPT
mechanism which allow us to intercept CR3 accessing. Then we pinned an Ubuntu
14.04 HVM to physical CPU 2 and 3 (we have 8 pCPUs). At the beginning of the
hvm startup, we use wrmsrl to set the MSR on each core (using the function
"on_each_cpu()") as 1 when exactly the domain is initialized (in
hvm_domain_initialise() of hvm.c). However, when we used rdmsrl to read the
value of MSR_IA32_DEBUGCTLMSR in every vm-exit cased by CR3 accessing (in
vmexit handler of vmx.c), we found the value had changed to be 0 on cpu 2 and
cpu 3, while others' (cpu 0, 1, 4 ,5, 6, and 7) were still 1. Moreover, when we
inserted some code (also in vmexit handler of vmx.c) to modify the values to be
1, somehow they sometimes just turned to 0 again when we read them in some CR3
access interceptions. So I was wondering if there are any mechanisms to clear
all bits of the IA32_DEBUGCTL MSR in Xen?
Thanks a lot in advance.
- Weijie.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
