similar to: branch tracing and MSR usage

Oops forgot to change the subject! Please find my email below Sujata Hi, I''m a student working on a research project using xen, and part of what we are doing requires the ability to use the branch tracing facilities of the processor. I.e. we need to be able to write to the IA32_DEBUGCTL MSR and read from the Last Branch Record (LBR) stack (the second of which it appears we can do). We

On 25/09/2017 06:44, Wei Wang wrote: > Passthrough the LBR stack to the guest, and auto switch the stack MSRs > upon VMEntry and VMExit. > > Signed-off-by: Wei Wang <wei.w.wang at intel.com> This has to be enabled separately for each guest, because it may prevent live migration to hosts with a different family/model. Paolo > --- > arch/x86/kvm/vmx.c | 50

On 25/09/2017 06:44, Wei Wang wrote: > Passthrough the LBR stack to the guest, and auto switch the stack MSRs > upon VMEntry and VMExit. > > Signed-off-by: Wei Wang <wei.w.wang at intel.com> This has to be enabled separately for each guest, because it may prevent live migration to hosts with a different family/model. Paolo > --- > arch/x86/kvm/vmx.c | 50

Hi I am working on a project using WINDOWS guest on XEN archticture. I have a couple of questions. As I understand when a VM exit occurs due to I/O like say a mouse interrupt -- the XEN hypervisor gets a notification and it forwards the I/O request to the qemu-dm in Domain-0 via an event channel. Now during this VM exit , is the guest OS blocked ? Specifically, what about VGA writes are they

Passthrough the LBR stack to the guest, and auto switch the stack MSRs upon VMEntry and VMExit. Signed-off-by: Wei Wang <wei.w.wang at intel.com> --- arch/x86/kvm/vmx.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 5f5c2f1..35e02a7 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c

This patch series enables the Last Branch Recording feature for the guest. Instead of trapping each LBR stack MSR access, the MSRs are passthroughed to the guest. Those MSRs are switched (i.e. load and saved) on VMExit and VMEntry. Test: Try "perf record -b ./test_program" on guest. Wei Wang (4): KVM/vmx: re-write the msr auto switch feature KVM/vmx: auto switch

This patch series enables the Last Branch Recording feature for the guest. Instead of trapping each LBR stack MSR access, the MSRs are passthroughed to the guest. Those MSRs are switched (i.e. load and saved) on VMExit and VMEntry. Test: Try "perf record -b ./test_program" on guest. Wei Wang (4): KVM/vmx: re-write the msr auto switch feature KVM/vmx: auto switch

This patch clarifies a vague statement in the SDM: the recommended maximum number of MSRs that can be automically switched by CPU during VMExit and VMEntry is 512, rather than 512 Bytes of MSRs. Depending on the CPU implementations, it may also support more than 512 MSRs to be auto switched. This can be calculated by (MSR_IA32_VMX_MISC[27:25] + 1) * 512. Signed-off-by: Wei Wang <wei.w.wang at

On 09/25/2017 10:59 PM, Andi Kleen wrote: > On Mon, Sep 25, 2017 at 12:44:52PM +0800, Wei Wang wrote: >> This patch series enables the Last Branch Recording feature for the >> guest. Instead of trapping each LBR stack MSR access, the MSRs are >> passthroughed to the guest. Those MSRs are switched (i.e. load and >> saved) on VMExit and VMEntry. >> >> Test:

On 09/25/2017 10:59 PM, Andi Kleen wrote: > On Mon, Sep 25, 2017 at 12:44:52PM +0800, Wei Wang wrote: >> This patch series enables the Last Branch Recording feature for the >> guest. Instead of trapping each LBR stack MSR access, the MSRs are >> passthroughed to the guest. Those MSRs are switched (i.e. load and >> saved) on VMExit and VMEntry. >> >> Test:

On Mon, Sep 25, 2017 at 12:44:52PM +0800, Wei Wang wrote: > This patch series enables the Last Branch Recording feature for the > guest. Instead of trapping each LBR stack MSR access, the MSRs are > passthroughed to the guest. Those MSRs are switched (i.e. load and > saved) on VMExit and VMEntry. > > Test: > Try "perf record -b ./test_program" on guest. I don't

> 1) vCPU context switching and guest side task switching are not identical. > That is, when the vCPU is scheduled out, the guest task on the vCPU may not guest task lifetime has nothing to do with this. It's completely independent of what you do here on the VCPU level. > run out its time slice yet, so the task will continue to run when the vCPU > is > scheduled in by the host

> 1) vCPU context switching and guest side task switching are not identical. > That is, when the vCPU is scheduled out, the guest task on the vCPU may not guest task lifetime has nothing to do with this. It's completely independent of what you do here on the VCPU level. > run out its time slice yet, so the task will continue to run when the vCPU > is > scheduled in by the host

The "APIC-register virtualization" and "virtual-interrupt deliver" VM-execution control has no effect on the behavior of RDMSR/WRMSR if the "virtualize x2APIC mode" VM-execution control is 0. When guest uses x2APIC mode, we should enable "virtualize x2APIC mode" for APICV first. Signed-off-by: Jiongxi Li <jiongxi.li@intel.com> diff --git

From 291adaf4ad6174c5641a7239c1801373e92e9975 Mon Sep 17 00:00:00 2001 From: Liu Jinsong <jinsong.liu@intel.com> Date: Thu, 28 Nov 2013 05:26:06 +0800 Subject: [PATCH v4 3/7] X86: MPX IA32_BNDCFGS msr handle When MPX supported, a new guest-state field for IA32_BNDCFGS is added to the VMCS. In addition, two new controls are added: - a VM-exit control called "clear BNDCFGS" - a

I recently realized that the original way of dealing with the DebugCtl MSR on VMX failed to make use of the dedicated guest VMCS field. This is being fixed with this patch. What is puzzling me to a certain degree is that while there is a guest VMCS field for this MSR, there''s no equivalent host load field, but there''s also no indication that the MSR would be cleared during a

Intercepting this MSR is pointless - The swapgs instruction does not cause a vmexit, so the cached result of this is potentially stale after the next guest instruction. It is correctly saved and restored on vcpu context switch. Furthermore, 64bit Windows writes to this MSR on every thread context switch, so interception causes a substantial performance hit. From: Paul Durrant

[PATCH 4/8] HVM save restore: vcpu context support Signed-off-by: Zhai Edwin <edwin.zhai@intel.com> save/restore HVM vcpu context such as vmcs diff -r ee20d1905bde xen/arch/x86/domain.c --- a/xen/arch/x86/domain.c Thu Jan 11 16:40:55 2007 +0800 +++ b/xen/arch/x86/domain.c Thu Jan 11 16:46:59 2007 +0800 @@ -573,6 +573,7 @@ int arch_set_info_guest( else {

On Thu, Sep 18, 2014 at 6:03 PM, Andy Lutomirski <luto at amacapital.net> wrote: > On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun <jun.nakajima at intel.com> wrote: >> On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski <luto at amacapital.net> wrote: >> >>> So, as a concrete straw-man: >>> >>> CPUID leaf 0x48000000 would return a maximum

On 09/25/2017 07:54 PM, Paolo Bonzini wrote: > On 25/09/2017 06:44, Wei Wang wrote: >> >> +static void update_msr_autoload_count_max(void) >> +{ >> + u64 vmx_msr; >> + int n; >> + >> + /* >> + * According to the Intel SDM, if Bits 27:25 of MSR_IA32_VMX_MISC is >> + * n, then (n + 1) * 512 is the recommended max number of MSRs to be