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: Haitao Shan <maillists.shan@xxxxxxxxx>
Subject: Re: [Xen-devel] [Patch] Allowing PV-OPS kernel to detect whether XSAVE is supported
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Tue, 09 Nov 2010 11:55:39 -0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Tue, 09 Nov 2010 11:56:34 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTi=dR3b7N5xUa2E=gLnVFdVWYX=S0fXN-g8OaJtP@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc13 Lightning/1.0b3pre Thunderbird/3.1.6
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.

> 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?

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.

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?

    J

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