| Message ID | 20200129144514.96686-3-roger.pau@citrix.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | nvmx: implement support for MSR bitmaps | expand |
> From: Roger Pau Monne <roger.pau@citrix.com> > Sent: Wednesday, January 29, 2020 10:45 PM > > Nested VMX doesn't expose support for > SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE, > SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or > SECONDARY_EXEC_APIC_REGISTER_VIRT, and hence the x2APIC MSRs should > always be trapped in the nested guest MSR bitmap, or else a nested > guest could access the hardware x2APIC MSRs given certain conditions. > > Accessing the hardware MSRs could be achieved by forcing the L0 Xen to > use SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE and > SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or > SECONDARY_EXEC_APIC_REGISTER_VIRT (if supported), and then creating a > L2 guest with a MSR bitmap that doesn't trap accesses to the x2APIC > MSR range. Then OR'ing both L0 and L1 MSR bitmaps would result in a > bitmap that doesn't trap certain x2APIC MSRs and a VMCS that doesn't > have SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE and > SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or > SECONDARY_EXEC_APIC_REGISTER_VIRT set either. > > Fix this by making sure x2APIC MSRs are always trapped in the nested > MSR bitmap. > > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index c35b4bab84..69dd4cf6ea 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -589,6 +589,16 @@ static void update_msrbitmap(struct vcpu *v) v->arch.hvm.vmx.msr_bitmap->write_high, sizeof(msr_bitmap->write_high) * 8); + /* + * Nested VMX doesn't support any x2APIC hardware virtualization, so + * make sure all the x2APIC MSRs are trapped. + */ + for ( msr = MSR_X2APIC_FIRST; msr <= MSR_X2APIC_FIRST + 0xff; msr++ ) + { + __set_bit(msr, msr_bitmap->read_low); + __set_bit(msr, msr_bitmap->write_low); + } + unmap_domain_page(msr_bitmap); __vmwrite(MSR_BITMAP, page_to_maddr(nvmx->msr_merged));
Nested VMX doesn't expose support for SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE, SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or SECONDARY_EXEC_APIC_REGISTER_VIRT, and hence the x2APIC MSRs should always be trapped in the nested guest MSR bitmap, or else a nested guest could access the hardware x2APIC MSRs given certain conditions. Accessing the hardware MSRs could be achieved by forcing the L0 Xen to use SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE and SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or SECONDARY_EXEC_APIC_REGISTER_VIRT (if supported), and then creating a L2 guest with a MSR bitmap that doesn't trap accesses to the x2APIC MSR range. Then OR'ing both L0 and L1 MSR bitmaps would result in a bitmap that doesn't trap certain x2APIC MSRs and a VMCS that doesn't have SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE and SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or SECONDARY_EXEC_APIC_REGISTER_VIRT set either. Fix this by making sure x2APIC MSRs are always trapped in the nested MSR bitmap. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> --- Changes since v1: - New in this version (split from #1 patch). - Use non-locked set_bit. --- xen/arch/x86/hvm/vmx/vvmx.c | 10 ++++++++++ 1 file changed, 10 insertions(+)