From: Wei Huang <wei.huang2@amd.com>
To: Roger Cruz <roger.cruz@virtualcomputer.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: Re: [PATCH] x86: clear CPUID output of leaf 0xd for Dom0 when xs
Date: Wed, 18 May 2011 15:38:45 -0500 [thread overview]
Message-ID: <4DD42E55.60300@amd.com> (raw)
In-Reply-To: <EACA7CA90354A849B1315959042A052C01094650@BE24.exg4.exghost.com>
[-- Attachment #1.1: Type: text/plain, Size: 2431 bytes --]
I think Jan's assumption is correct. All future extension (from either
Intel or AMD) will be xsave related. If xsave is disabled, then these
extensions should be zapped, not just XSAVEOPT.
Regarding sub-leaves of CPUID 0x0D, software is supposed to check
CPUID_0xD_subleaf_0[EAX:EDX] before retrieving the values of other
sub-leaves. If it doesn't follow this step, software has a benign issue
(I don't call it bug). According to spec, cpuid instruction doesn't
forbid software to check unsupported CPUID. Returning 0's is enough I think.
Regards,
-Wei
On 05/18/2011 02:58 PM, Roger Cruz wrote:
>
> 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
> cleared.)
>
> 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);
> 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 */
>
>
[-- Attachment #1.2: Type: text/html, Size: 4412 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
prev parent reply other threads:[~2011-05-18 20:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-18 19:58 [PATCH] x86: clear CPUID output of leaf 0xd for Dom0 when xs Roger Cruz
2011-05-18 20:38 ` Wei Huang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DD42E55.60300@amd.com \
--to=wei.huang2@amd.com \
--cc=roger.cruz@virtualcomputer.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).