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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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 &=
> > > > +            ~(SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES
> > > > +              | SECONDARY_EXEC_APIC_REGISTER_VIRT
> > > > +              | SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY);
> > > > +        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 &=
> > > > +            ~(SECONDARY_EXEC_UNRESTRICTED_GUEST
> > > > +              | SECONDARY_EXEC_WBINVD_EXITING);
> > > 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,
> > > > MSR_TYPE_R | MSR_TYPE_W);
> > > > +
> > > > +        /*
> > > > +         * PVH: We don't disable intercepts for MSRs: MSR_STAR,
> > > > MSR_LSTAR,
> > > > +         *      MSR_CSTAR, and MSR_SYSCALL_MASK because we need to
> > > > specify
> > > > +         *      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
> > > > vmx_restore_host_msrs().
> > > > +         *      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
> > MSR_SHADOW_GS_BASE.
> 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
> change.
>
> 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.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel