On Thu, Nov 18, 2021, Paolo Bonzini wrote: > On 11/18/21 12:08, Lai Jiangshan wrote: > > From: Lai Jiangshan <laijs@xxxxxxxxxxxxxxxxx> > > > > And adds a corresponding sanity check code. > > > > Signed-off-by: Lai Jiangshan <laijs@xxxxxxxxxxxxxxxxx> > > --- > > arch/x86/kvm/vmx/vmx.c | 10 +++++++++- > > 1 file changed, 9 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > > index e8a41fdc3c4d..cd081219b668 100644 > > --- a/arch/x86/kvm/vmx/vmx.c > > +++ b/arch/x86/kvm/vmx/vmx.c > > @@ -3703,13 +3703,21 @@ void vmx_disable_intercept_for_msr(struct kvm_vcpu *vcpu, u32 msr, int type) > > if (!cpu_has_vmx_msr_bitmap()) > > return; > > + /* > > + * Write to uret msr should always be intercepted due to the mechanism > > + * must know the current value. Santity check to avoid any inadvertent > > + * mistake in coding. > > + */ > > + if (WARN_ON_ONCE(vmx_find_uret_msr(vmx, msr) && (type & MSR_TYPE_W))) > > + return; > > + > > I'm not sure about this one, it's relatively expensive to call > vmx_find_uret_msr. > > User-return MSRs and disable-intercept MSRs are almost the opposite: uret is > for MSRs that the host (not even the processor) never uses, > disable-intercept is for MSRs that the guest reads/writes often. As such it > seems almost impossible that they overlap. And they aren't fundamentally mutually exclusive, e.g. KVM could pass-through an MSR and then do RDMSR in vmx_prepare_switch_to_host() to refresh the uret data with the current (guest) value. It'd be silly, but it would work.
