diff mbox

[5/6] x86/vvmx: Fix handing of the MSR_BITMAP field with VMCS shadowing

Message ID 1500465477-23793-6-git-send-email-andrew.cooper3@citrix.com (mailing list archive)
State New, archived
Headers show

Commit Message

Andrew Cooper July 19, 2017, 11:57 a.m. UTC
Currently, the following sequence of actions:

 * VMPTRLD (creates a mapping, likely pointing at gfn 0 for an empty vmcs)
 * VMWRITE CPU_BASED_VM_EXEC_CONTROL (completed by hardware)
 * VMWRITE MSR_BITMAP (completed by hardware)
 * VMLAUNCH

results in an L2 guest running with ACTIVATE_MSR_BITMAP set, but Xen using a
stale mapping (likely gfn 0) when reading the interception bitmap.  The
MSR_BITMAP field needs unconditionally intercepting even with VMCS shadowing,
so Xen's mapping of the bitmap can be updated.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Jun Nakajima <jun.nakajima@intel.com>
CC: Kevin Tian <kevin.tian@intel.com>
---
 xen/arch/x86/hvm/vmx/vvmx.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Comments

Sergey Dyasli July 26, 2017, 8:50 a.m. UTC | #1
On Wed, 2017-07-19 at 12:57 +0100, Andrew Cooper wrote:
> Currently, the following sequence of actions:

> 

>  * VMPTRLD (creates a mapping, likely pointing at gfn 0 for an empty vmcs)

>  * VMWRITE CPU_BASED_VM_EXEC_CONTROL (completed by hardware)

>  * VMWRITE MSR_BITMAP (completed by hardware)

>  * VMLAUNCH

> 

> results in an L2 guest running with ACTIVATE_MSR_BITMAP set, but Xen using a

> stale mapping (likely gfn 0) when reading the interception bitmap.  The

> MSR_BITMAP field needs unconditionally intercepting even with VMCS shadowing,

> so Xen's mapping of the bitmap can be updated.

> 

> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>


Reviewed-by: Sergey Dyasli <sergey.dyasli@citrix.com>


-- 
Thanks,
Sergey
Tian, Kevin July 27, 2017, 6:11 a.m. UTC | #2
> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> Sent: Wednesday, July 19, 2017 7:58 PM
> 
> Currently, the following sequence of actions:
> 
>  * VMPTRLD (creates a mapping, likely pointing at gfn 0 for an empty vmcs)
>  * VMWRITE CPU_BASED_VM_EXEC_CONTROL (completed by hardware)
>  * VMWRITE MSR_BITMAP (completed by hardware)
>  * VMLAUNCH
> 
> results in an L2 guest running with ACTIVATE_MSR_BITMAP set, but Xen
> using a
> stale mapping (likely gfn 0) when reading the interception bitmap.  The
> MSR_BITMAP field needs unconditionally intercepting even with VMCS
> shadowing,
> so Xen's mapping of the bitmap can be updated.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Kevin Tian <kevin.tian@intel.com>
diff mbox

Patch

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 0d08789..f84478e 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -98,13 +98,15 @@  int nvmx_vcpu_initialise(struct vcpu *v)
         clear_page(vw);
 
         /*
-         * For the following 4 encodings, we need to handle them in VMM.
+         * For the following 6 encodings, we need to handle them in VMM.
          * Let them vmexit as usual.
          */
         set_bit(IO_BITMAP_A, vw);
         set_bit(VMCS_HIGH(IO_BITMAP_A), vw);
         set_bit(IO_BITMAP_B, vw);
         set_bit(VMCS_HIGH(IO_BITMAP_B), vw);
+        set_bit(MSR_BITMAP, vw);
+        set_bit(VMCS_HIGH(MSR_BITMAP), vw);
 
         unmap_domain_page(vw);
     }