thr3ads.net - Xen devel - [Xen-devel] [PATCH] x86: clear CPUID output of leaf 0xd for Dom0 when xsave is disabled [May 2011]

If this information is useful, please help other people find it:
Share via:

Jan Beulich

2011-May-18 09:53 UTC

[Xen-devel] [PATCH] x86: clear CPUID output of leaf 0xd for Dom0 when xsave is disabled

Linux starting with 2.6.36 uses the XSAVEOPT instruction and has
certain code paths that look only at the feature bit reported through
CPUID leaf 0xd sub-leaf 1 (i.e. without qualifying the check with one
evaluating leaf 4 output). Consequently the hypervisor ought to mimic
actual hardware in clearing leaf 0xd output when not supporting xsave.

(Note that this is only a minimal fix. It may be necessary, e.g. for
LWP, to also adjust sub-leaf 0''s bit masks and perhaps zap output of
sub-leaves > 1 when the respective bit in sub-leaf 0 is getting
cleared.)

Signed-off-by: Jan Beulich <jbeulich@novell.com>

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -836,6 +836,10 @@ static void pv_cpuid(struct cpu_user_reg
         __clear_bit(X86_FEATURE_NODEID_MSR % 32, &c);
         __clear_bit(X86_FEATURE_TOPOEXT % 32, &c);
         break;
+    case 0xd: /* XSAVE */
+        if ( xsave_enabled(current) )
+            break;
+        /* fall through */
     case 5: /* MONITOR/MWAIT */
     case 0xa: /* Architectural Performance Monitor Features */
     case 0x8000000a: /* SVM revision and features */





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

Wei Huang

2011-May-18 21:01 UTC

head link

Re: [Xen-devel] [PATCH] x86: clear CPUID output of leaf 0xd for Dom0 when xsave is disabled

I tested cpuid on a real hardware. If software wants, reading all 
sub-leaves are allowed even on hardware which doesn''t support XSAVE.
The
instruction just returns 0. So I don''t think we need to zap output for 
sub-leaves > 1.


    0x0000000c 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 
edx=0x00000000
    0x0000000d 0x00: eax=0x00000003 ebx=0x00000240 ecx=0x00000240 
edx=0x00000000
    0x0000000d 0x02: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 
edx=0x00000000
    0x0000000d 0x3e: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 
edx=0x00000000

On 05/18/2011 04:53 AM, Jan Beulich wrote:> Linux starting with 2.6.36 uses the XSAVEOPT instruction and has
> certain code paths that look only at the feature bit reported through
> CPUID leaf 0xd sub-leaf 1 (i.e. without qualifying the check with one
> evaluating leaf 4 output). Consequently the hypervisor ought to mimic
> actual hardware in clearing leaf 0xd output when not supporting xsave.
>
> (Note that this is only a minimal fix. It may be necessary, e.g. for
> LWP, to also adjust sub-leaf 0''s bit masks and perhaps zap output
of
> sub-leaves>  1 when the respective bit in sub-leaf 0 is getting
> cleared.)
>
> Signed-off-by: Jan Beulich<jbeulich@novell.com>
>
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -836,6 +836,10 @@ static void pv_cpuid(struct cpu_user_reg
>           __clear_bit(X86_FEATURE_NODEID_MSR % 32,&c);
>           __clear_bit(X86_FEATURE_TOPOEXT % 32,&c);
>           break;
> +    case 0xd: /* XSAVE */
> +        if ( xsave_enabled(current) )
> +            break;
> +        /* fall through */
>       case 5: /* MONITOR/MWAIT */
>       case 0xa: /* Architectural Performance Monitor Features */
>       case 0x8000000a: /* SVM revision and features */
>
>
>


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

Jan Beulich

2011-May-19 06:47 UTC

head link

Re: [Xen-devel] [PATCH] x86: clear CPUID output of leaf 0xd for Dom0 when xsave is disabled

>>> On 18.05.11 at 23:01, Wei Huang <wei.huang2@amd.com> wrote:
> I tested cpuid on a real hardware. If software wants, reading all 
> sub-leaves are allowed even on hardware which doesn''t support
XSAVE. The
> instruction just returns 0. So I don''t think we need to zap output
for
> sub-leaves > 1.
"Returning zero" is what "zapping" means to me. Returning
non-zero
possibly mis-guiding OSes (just as is the case with the xsaveopt
feature flag in Linux) is what I want to avoid.

Jan
>     0x0000000c 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 
> edx=0x00000000
>     0x0000000d 0x00: eax=0x00000003 ebx=0x00000240 ecx=0x00000240 
> edx=0x00000000
>     0x0000000d 0x02: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 
> edx=0x00000000
>     0x0000000d 0x3e: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 
> edx=0x00000000
> 
> On 05/18/2011 04:53 AM, Jan Beulich wrote:
>> Linux starting with 2.6.36 uses the XSAVEOPT instruction and has
>> certain code paths that look only at the feature bit reported through
>> CPUID leaf 0xd sub-leaf 1 (i.e. without qualifying the check with one
>> evaluating leaf 4 output). Consequently the hypervisor ought to mimic
>> actual hardware in clearing leaf 0xd output when not supporting xsave.
>>
>> (Note that this is only a minimal fix. It may be necessary, e.g. for
>> LWP, to also adjust sub-leaf 0''s bit masks and perhaps zap
output of
>> sub-leaves>  1 when the respective bit in sub-leaf 0 is getting
>> cleared.)
>>
>> Signed-off-by: Jan Beulich<jbeulich@novell.com>
>>
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -836,6 +836,10 @@ static void pv_cpuid(struct cpu_user_reg
>>           __clear_bit(X86_FEATURE_NODEID_MSR % 32,&c);
>>           __clear_bit(X86_FEATURE_TOPOEXT % 32,&c);
>>           break;
>> +    case 0xd: /* XSAVE */
>> +        if ( xsave_enabled(current) )
>> +            break;
>> +        /* fall through */
>>       case 5: /* MONITOR/MWAIT */
>>       case 0xa: /* Architectural Performance Monitor Features */
>>       case 0x8000000a: /* SVM revision and features */
>>
>>
>>



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

Jan Beulich

2011-May-20 07:08 UTC

head link

RE: [Xen-devel] [PATCH] x86: clear CPUID output of leaf 0xd for Dom0 when xsave is disabled

>>> On 19.05.11 at 18:08, "Huang2, Wei"
<Wei.Huang2@amd.com> wrote:
> That is right. Could you slip it into your patch and I can sign it off? Or
I
> can crank up one. Keir hasn''t put your patch into tree yet.
I would specifically want this change to be separate from the one I did.

Jan
> Thanks,
> -Wei
> 
> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@novell.com] 
> Sent: Thursday, May 19, 2011 11:06 AM
> To: Huang2, Wei
> Subject: Re: [Xen-devel] [PATCH] x86: clear CPUID output of leaf 0xd for
Dom0
> when xsave is disabled
> 
>>>> On 19.05.11 at 17:34, Wei Huang <wei.huang2@amd.com>
wrote:
>> I misunderstood your email then. Doesn''t your patch already
achieve this
>> objective? We didn''t check sub-leaf ID (ECX) in switch-case
statement.
>> So all sub-leaves will be cleaned out by your patch.
> 
> Exactly - all of them. However, with LWP currently supported for HVM
> guests only, the respective leaf should be cleared for Dom0 (while not
> clearing the others).
> 
> Jan
> 
>> -Wei
>> 
>> On 05/19/2011 01:47 AM, Jan Beulich wrote:
>>>>>> On 18.05.11 at 23:01, Wei
Huang<wei.huang2@amd.com>  wrote:
>>>> I tested cpuid on a real hardware. If software wants, reading
all
>>>> sub-leaves are allowed even on hardware which doesn''t
support XSAVE. The
>>>> instruction just returns 0. So I don''t think we need
to zap output for
>>>> sub-leaves>  1.
>>> "Returning zero" is what "zapping" means to me.
Returning non-zero
>>> possibly mis-guiding OSes (just as is the case with the xsaveopt
>>> feature flag in Linux) is what I want to avoid.
>>>
>>> Jan
>>>
>>>>      0x0000000c 0x00: eax=0x00000000 ebx=0x00000000
ecx=0x00000000
>>>> edx=0x00000000
>>>>      0x0000000d 0x00: eax=0x00000003 ebx=0x00000240
ecx=0x00000240
>>>> edx=0x00000000
>>>>      0x0000000d 0x02: eax=0x00000000 ebx=0x00000000
ecx=0x00000000
>>>> edx=0x00000000
>>>>      0x0000000d 0x3e: eax=0x00000000 ebx=0x00000000
ecx=0x00000000
>>>> edx=0x00000000
>>>>
>>>> On 05/18/2011 04:53 AM, Jan Beulich wrote:
>>>>> Linux starting with 2.6.36 uses the XSAVEOPT instruction
and has
>>>>> certain code paths that look only at the feature bit
reported through
>>>>> CPUID leaf 0xd sub-leaf 1 (i.e. without qualifying the
check with one
>>>>> evaluating leaf 4 output). Consequently the hypervisor
ought to mimic
>>>>> actual hardware in clearing leaf 0xd output when not
supporting xsave.
>>>>>
>>>>> (Note that this is only a minimal fix. It may be necessary,
e.g. for
>>>>> LWP, to also adjust sub-leaf 0''s bit masks and
perhaps zap output of
>>>>> sub-leaves>   1 when the respective bit in sub-leaf 0 is
getting
>>>>> cleared.)
>>>>>
>>>>> Signed-off-by: Jan Beulich<jbeulich@novell.com>
>>>>>
>>>>> --- a/xen/arch/x86/traps.c
>>>>> +++ b/xen/arch/x86/traps.c
>>>>> @@ -836,6 +836,10 @@ static void pv_cpuid(struct
cpu_user_reg
>>>>>            __clear_bit(X86_FEATURE_NODEID_MSR % 32,&c);
>>>>>            __clear_bit(X86_FEATURE_TOPOEXT % 32,&c);
>>>>>            break;
>>>>> +    case 0xd: /* XSAVE */
>>>>> +        if ( xsave_enabled(current) )
>>>>> +            break;
>>>>> +        /* fall through */
>>>>>        case 5: /* MONITOR/MWAIT */
>>>>>        case 0xa: /* Architectural Performance Monitor
Features */
>>>>>        case 0x8000000a: /* SVM revision and features */
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>



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

Xen devel - May 2011 - [PATCH] x86: clear CPUID output of leaf 0xd for Dom0 when xsave is disabled

[Xen-devel] [PATCH] x86: clear CPUID output of leaf 0xd for Dom0 when xsave is disabled

Re: [Xen-devel] [PATCH] x86: clear CPUID output of leaf 0xd for Dom0 when xsave is disabled

Re: [Xen-devel] [PATCH] x86: clear CPUID output of leaf 0xd for Dom0 when xsave is disabled

RE: [Xen-devel] [PATCH] x86: clear CPUID output of leaf 0xd for Dom0 when xsave is disabled