| On 28/10/2017 13:40, 刘维杰 wrote:
 
      
      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
 Unrelated to your problem, Xen 4.6 is very old and you should
    consider using a newer version.
 
 
 
      
        (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? Yes.  Because of the default settings Xen has, hardware resets the
    value on vmentry.
 
 
 
      
        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.
 Read in the architecture about VM entry and exit controls, and
    save/load host/guest debug control settings.
 
 The guest has its own DEBUGCTL setting, and a vmentry/exit will
    modify the value in use.  If you want the guest to be running with
    LBR enabled, you will have to modify the guest value.
 
 
 
      BTW, to get the some useful information from LBR, we first
        disabled EPT mechanism which allow us to intercept CR3
        accessing.
 Why?  You can enable CR3 intercepts without disabling EPT, although
    you will have to alter the vmexit handler to not enter into the
    shadow paging code.
 
 ~Andrew
 
 
 
      
        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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
 
 |