| Message ID | 20200204173455.22020-4-roger.pau@citrix.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | nvmx: implement support for MSR bitmaps | expand |
On 04.02.2020 18:34, Roger Pau Monne wrote: > --- a/xen/arch/x86/hvm/vmx/vvmx.c > +++ b/xen/arch/x86/hvm/vmx/vvmx.c > @@ -596,6 +596,13 @@ static void update_msrbitmap(struct vcpu *v, uint32_t shadow_ctrl) > 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. > + */ > + bitmap_set(msr_bitmap->read_low, MSR_X2APIC_FIRST, 0xff); > + bitmap_set(msr_bitmap->write_low, MSR_X2APIC_FIRST, 0xff); If you decide to address the Arm issue with these functions, and hence don't go back to the v3 variant, then the last arguments here need to be 0x100 afaict. Jan
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index 46c51a95b9..56e0d884b8 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -596,6 +596,13 @@ static void update_msrbitmap(struct vcpu *v, uint32_t shadow_ctrl) 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. + */ + bitmap_set(msr_bitmap->read_low, MSR_X2APIC_FIRST, 0xff); + bitmap_set(msr_bitmap->write_low, MSR_X2APIC_FIRST, 0xff); + 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 v3: - Use bitmap_set. Changes since v1: - New in this version (split from #1 patch). - Use non-locked set_bit. --- xen/arch/x86/hvm/vmx/vvmx.c | 7 +++++++ 1 file changed, 7 insertions(+)