From mboxrd@z Thu Jan  1 00:00:00 1970
From: George Dunlap <george.dunlap@eu.citrix.com>
Subject: Re: [PATCH v14 07/17] pvh: vmx-specific changes
Date: Thu, 7 Nov 2013 15:43:58 +0000
Message-ID: <527BB53E.30606@eu.citrix.com>
References: <1383567306-6636-1-git-send-email-george.dunlap@eu.citrix.com>
	<1383567306-6636-8-git-send-email-george.dunlap@eu.citrix.com>
	<20131107002713.GD32964@deinos.phlegethon.org>
	<527BA8AC.3030905@eu.citrix.com> <527BB451.9010707@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <527BB451.9010707@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>, Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

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