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/
Home Products Support Community News


[Xen-devel] Re: [PATCH] x86: clear CPUID output of leaf 0xd for Dom0 whe

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] x86: clear CPUID output of leaf 0xd for Dom0 when xs
From: "Roger Cruz" <roger.cruz@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 18 May 2011 14:58:35 -0500
Delivery-date: Wed, 18 May 2011 12:59:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwVlfiTSoFp1WbpQY+jv6wHb74S3w==
Thread-topic: [PATCH] x86: clear CPUID output of leaf 0xd for Dom0 when xs

Hi Jan,

I was wondering if we should not let the code fall through and clear all registers to zero but rather clear just the one bit we care about?  My concern is that a future Intel revision may expand this function and return other information besides that XSAVEOPT, which would then be wiped out by the fall-through code.  I'm thinking something like this.  Let me know if I have misunderstood something.

+   case 0xd: /* XSAVE */
+        if (!xsave_enabled(current))
+            __clear_bit(X86_FEATURE_XSAVEOPT % 32, &a);
+        break;
    case 5: /* MONITOR/MWAIT */

Roger R. Cruz


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

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>

--- 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);
+    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
<Prev in Thread] Current Thread [Next in Thread>