On Mon, Apr 12, 2021, Krish Sadhukhan wrote: > According to APM vol 2, hardware ignores the low 12 bits in MSRPM and IOPM > bitmaps. Therefore setting/unssetting these bits has no effect as far as > VMRUN is concerned. Also, setting/unsetting these bits prevents tests from > verifying hardware behavior. > > Signed-off-by: Krish Sadhukhan <krish.sadhukhan@xxxxxxxxxx> > --- > arch/x86/kvm/svm/nested.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c > index ae53ae46ebca..fd42c8b7f99a 100644 > --- a/arch/x86/kvm/svm/nested.c > +++ b/arch/x86/kvm/svm/nested.c > @@ -287,8 +287,6 @@ static void nested_load_control_from_vmcb12(struct vcpu_svm *svm, > > /* Copy it here because nested_svm_check_controls will check it. */ > svm->nested.ctl.asid = control->asid; > - svm->nested.ctl.msrpm_base_pa &= ~0x0fffULL; > - svm->nested.ctl.iopm_base_pa &= ~0x0fffULL; This will break nested_svm_vmrun_msrpm() if L1 passes an unaligned address. The shortlog is also wrong, KVM isn't setting bits, it's clearing bits. I also don't think svm->nested.ctl.msrpm_base_pa makes its way to hardware; IIUC, it's a copy of vmcs12->control.msrpm_base_pa. The bitmap that gets loaded into the "real" VMCB is vmcb02->control.msrpm_base_pa. > } > > /* > -- > 2.27.0 >
