On 30/01/2018 11:23, Radim Krčmář wrote: > 2018-01-27 09:50+0100, Paolo Bonzini: >> Place the MSR bitmap in struct loaded_vmcs, and update it in place >> every time the x2apic or APICv state can change. This is rare and >> the loop can handle 64 MSRs per iteration, in a similar fashion as >> nested_vmx_prepare_msr_bitmap. >> >> This prepares for choosing, on a per-VM basis, whether to intercept >> the SPEC_CTRL and PRED_CMD MSRs. >> >> Suggested-by: Jim Mattson <jmatt...@google.com> >> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> >> --- >> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c >> @@ -10022,7 +10043,7 @@ static inline bool >> nested_vmx_merge_msr_bitmap(struct kvm_vcpu *vcpu, >> int msr; >> struct page *page; >> unsigned long *msr_bitmap_l1; >> - unsigned long *msr_bitmap_l0 = to_vmx(vcpu)->nested.msr_bitmap; >> + unsigned long *msr_bitmap_l0 = to_vmx(vcpu)->nested.vmcs02.msr_bitmap; > > The physical address of the nested msr_bitmap is never loaded into vmcs. > > The resolution you provided had extra hunk in prepare_vmcs02_full(): > > + vmcs_write64(MSR_BITMAP, __pa(vmx->nested.vmcs02.msr_bitmap)); > > I have queued that as: > > + if (cpu_has_vmx_msr_bitmap()) > + vmcs_write64(MSR_BITMAP, __pa(vmx->nested.vmcs02.msr_bitmap));
Hmm you're right, it should be in prepare_vmcs02() here (4.15-based), and then moved to prepare_vmcs02_full() as part of the conflict resolution. I'll send a v3. Paolo
