WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [Patch] Allowing PV-OPS kernel to detect whether XSAVE i

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [Patch] Allowing PV-OPS kernel to detect whether XSAVE is supported
From: Haitao Shan <maillists.shan@xxxxxxxxx>
Date: Wed, 10 Nov 2010 08:18:26 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Tue, 09 Nov 2010 16:19:17 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=e9/iC4F/GqAB/fPSn2EZLacmA7Lh66nBRM78ln1rCtg=; b=xap6+2BBzHyeHpXAbVUUBFiMWqh0b6zUpFIwwSB1nZteGiHdj7wa51jTAZFyX3sbV1 ALftitK8l3EPkmqkxY/lNNxVpusLgIUIgKWMJZsC2zIxdcSp7/Es6IzwcOy8E2dmqw98 y68Y10Y+Mis821wp73lmd+RVHqQAxje3Qa8is=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GoycD7zI4NomCRHKhuyhkgC47gXjzIDNC6v36ai3mA4OhH7y7LRI2JkC+hO6UhwDj5 gwVRfHZROslZVQC7huzJ623QV6Yz6V5bjzBmsmfw3GmlGgODi0BXfG8yNA/45CHE/AoC tEMEnyHgB855ar+MBk75qxiXRVPvWkIdVNaAs=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTimeXpoC08=RLGxsQZSrf4EjR2vvCFHtuhjr+eNb@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTi=dR3b7N5xUa2E=gLnVFdVWYX=S0fXN-g8OaJtP@xxxxxxxxxxxxxx> <4CD9A73B.2070909@xxxxxxxx> <AANLkTimeXpoC08=RLGxsQZSrf4EjR2vvCFHtuhjr+eNb@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> Otherwise, usermode will either see both are set or unset. Since on a

Oh, that is not correct. I mean whenever user mode sees OSXSAVE, it
sees both are set or unset. If user mode sees XSAVE only, that is
legal of course.

Shan Haitao

2010/11/10 Haitao Shan <maillists.shan@xxxxxxxxx>:
> 2010/11/10 Jeremy Fitzhardinge <jeremy@xxxxxxxx>:
>> On 11/08/2010 10:22 PM, Haitao Shan wrote:
>>> Hi, Jeremy,
>>>
>>> This patch allows pv-ops kernel to detect whether XSAVE is supported
>>> (before masking it unconditionally through xen_cpuid).
>>> Can you please have review? Thanks!
>>>
>>> Signed-off-by: Shan Haitao <haitao.shan@xxxxxxxxx>
>>>
>>> Shan Haitao
>>>
>>
>> For future reference:
>>
>> Please post patches inline if possible.
>>
>> If you must use an attachment to prevent your mail system from
>> corrupting the patch, please include a complete description of the patch
>> (what is it trying to do, how does it do it, what is the outcome?) with
>> signed-off-bys in the the patch itself.
> OK. I will follow.
>
>>
>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index
>>> fd3803e..03bfaf7 100644 --- a/arch/x86/xen/enlighten.c +++
>>> b/arch/x86/xen/enlighten.c @@ -252,6 +252,13 @@ static __init void
>>> xen_init_cpuid_mask(void) (1 << X86_FEATURE_MCA) | /* disable MCA */
>>> (1 << X86_FEATURE_APIC) | /* disable local APIC */ (1 <<
>>> X86_FEATURE_ACPI)); /* disable ACPI */ + ax = 1; + xen_cpuid(&ax, &bx,
>>> &cx, &dx); + + /* Xen will set CR4.OSXSAVE if supported and not
>>> disabled by force */ + if ( cx & (1 << (X86_FEATURE_XSAVE % 32)) && +
>>> cx & (1 << (X86_FEATURE_OSXSAVE % 32)) ) + return;
>>> cpuid_leaf1_ecx_mask &= ~(1 << (X86_FEATURE_XSAVE % 32)); /* disable
>>> XSAVE */
>>
>>
>> I cleaned this up a bit (fixed formatting to Linux style, reversed the
>> sense of the if() and masked OSXSAVE as well, even though it won't make
>> a difference).  But I'm still a bit concerned about the back-compat
>> issues around this.
>>
>> What happens if the guest OS does not support XSAVE (older versions of
>> Linux)?  Could usermode code see OSXSAVE set in the cpuid feature flags
>> and attempt to use XSAVE, even if XSAVE isn't set?  In other words, can
>> usermode ever normally see OSXSAVE set, but XSAVE clear?
> I think that is not possible. If usermode does not use native CPUID
> instruction, or CPUID can be virtualized any way, this won't happen.
> Otherwise, usermode will either see both are set or unset. Since on a
> NON-XSAVE processor, you can not set CR4.OSXSAVE and won't be
> reflected to CPUID.
>
> If user mode sees both are set, they can use it actually. So we
> initially set FP and SSE in XCR0 for guest. If user mode wants to use
> it, guest kernel still can manage the state using traditional FPU
> save/restore mechanism. If user mode wants to access more extended
> states, it has to acquire kernel's support for turning on related bit
> in XCR0, which is finally controlled by Xen now.
>
> That's the reason I chose to turn on OSXSAVE in Xen and don't
> dynamically change it.
>
>>
>> We can't mask OSXSAVE to usermode because they can run the naked CPUID
>> instruction, so I guess the only way to cause it to be cleared would be
>> to clear CR4.OSXSAVE?  But that seems like a very expensive thing to do
>> on a vcpu context switch.
> Yes. This is the biggest concern when I wrote XSAVE patches.
> Otherwise, you will need to switch CR4 on entry to/exit from guest
> mode. Or as you said, switching CR4 when do a vcpu context switch, but
> whenever Xen itself want to use XSAVE instructions, it needs to turns
> on it and off it on the fly.
>
>>
>> How much testing of real usermode code have you done with this?  How
>> many combinations of XSAVE support in Xen, Linux and usermode have you
>> tried?
> I have a few AVX test programs running both inside PV guest and HVM.
> However, I have to admit that my aim is to test Xen's fpu context
> switching using Xsave and guest save/restore.
>
>>
>>    J
>>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel