On 2015/11/11 23:23, Paolo Bonzini wrote:
On 23/10/2015 11:15, Jian Zhou wrote:Changelog in v2: (1) move the implementation into vmx.c (2) migraton is supported (3) add arrays in kvm_vcpu_arch struct to save/restore LBR MSRs at vm exit/entry time. (4) add a parameter of kvm_intel module to permanently disable LBRV (5) table of supported CPUs is reorgnized, LBRV can be enabled or not according to the guest CPUID Jian Zhou (4): KVM: X86: Add arrays to save/restore LBR MSRs KVM: X86: LBR MSRs of supported CPU types KVM: X86: Migration is supported KVM: VMX: details of LBR virtualization implementation arch/x86/include/asm/kvm_host.h | 26 ++++- arch/x86/include/asm/msr-index.h | 26 ++++- arch/x86/kvm/vmx.c | 245 +++++++++++++++++++++++++++++++++++++++ arch/x86/kvm/x86.c | 88 ++++++++++++-- 4 files changed, 366 insertions(+), 19 deletions(-)Thanks, this looks better! The reason why it took me so long to review it, is that I wanted to understand what happens if you're running this on CPU model x but using CPU model y for the guest. I still haven't grokked that fully, so I'll apply your patches locally and play with them.
Yes, that is a good question. I plan to write a kernel module in the guest to read/write the MSR_IA32_DEBUGCTLMSR and MSRs of LBR stack with host CPU model e.g. SandyBridge while using guest CPU model e.g. core2duo for the guest. (The address of MSRs recording last branch information between SandyBridge and core2duo is different)
In the meanwhile, feel free to send v3 with: 1) the tweak I suggested to patch 3; 2) the fix for the problem that the buildbot reported on patch 1.
Okay, will fix them in v3. Thanks, Jian
Paolo .
-- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
