[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v14 07/17] pvh: vmx-specific changes

On 07/11/13 15:40, Andrew Cooper wrote:
On 07/11/13 14:50, George Dunlap wrote:
On 07/11/13 00:27, Tim Deegan wrote:
At 12:14 +0000 on 04 Nov (1383563696), George Dunlap wrote:
+    if ( is_pvh_domain(d) )
+    {
+        /* Disable virtual apics, TPR */
+        v->arch.hvm_vmx.secondary_exec_control &=
+        v->arch.hvm_vmx.exec_control &= ~CPU_BASED_TPR_SHADOW;
+        /* Disable wbinvd (only necessary for MMIO),
+         * unrestricted guest (real mode for EPT) */
+        v->arch.hvm_vmx.secondary_exec_control &=
WBINVD exiting is used for supporting _real_ MMIO, which PVH guetst
will still have, right?

+        if ( is_pvh_domain(d) )
+            vmx_disable_intercept_for_msr(v, MSR_SHADOW_GS_BASE,
+        /*
+         * PVH: We don't disable intercepts for MSRs: MSR_STAR,
+         *      MSR_CSTAR, and MSR_SYSCALL_MASK because we need to
+         *      save/restore area to save/restore at every VM exit
and entry.
+         *      Instead, let the intercept functions save them into
+         *      vmx_msr_state fields. See comment in
+         *      See also vmx_restore_guest_msrs().
+         */
Why are these MSRs special for PVH guests?  Are PVH guests restricted
in how they can use SHADOW_GS?
Your real question is, why is GS_BASE *less* restricted for PVH mode:
in HVM mode (as far as I can tell), we exit on accesses to
As far as this exiting goes, Paul and I looked at it and considered it
bogus in context.  We have turned it off in XenServer trunk and are
waiting for XenRT to test it thoroughly before formally upstreaming the

A partner has indicated that it leads to an order of magnitude
performance degradation for 64bit windows which appears to rewrite
GS_BASE on every context switch.

Excellent -- I'll take it off my list.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.