On Wed, Jan 28, 2015 at 9:06 PM, Zhang, Yang Z <yang.z.zhang@xxxxxxxxx> wrote: >>>> __clear_bit(msr, msr_bitmap_nested + 0x000 / f); >>> >>> >>> Anyway, this is not necessary for your current patch. We can consider >>> it later if there really have other features will use it. >>> >> >> Yep, I know what you mean now, for other msrs which are not forwarded >> access by a mechanism like virtual-apic page, we should intercept it >> unconditionally. I think we should ensure the msr can be allowed >> before call nested_vmx_disable_intercept_for_msr, if L0 want to >> intercept it, just do not call nested_vmx_disable_intercept_for_msr. > > Yes, this is a solution. But I prefer to handle it in nested code path since others may not familiar with nested and may block it by mistake. > >> >> !test_bit(msr, vmcs01_msr_bitmap) will introduce a problem that some >> of the msrs will be affcted by vmcs01_msr_bitmap, TMCCT and TPR, for example. >> Intercept reading for these msrs is okay, but it is not efficient. > > TMCCT is always trapped by most VMM. I don't think TPR is trapped in KVM. > Oooops. This piece of code made me confused and I was not think about that words, just forget it. ( * ^ _ ^ * ) vmx_enable_intercept_msr_read_x2apic(0x802); /* TMCCT */ vmx_enable_intercept_msr_read_x2apic(0x839); /* TPR */ If there are any features use it in the future, let's consider about this, thank you for your patience. Thanks, Wincy -- 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