From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: RE: [PATCH] x86: clear CPUID output of leaf 0xd for Dom0 when xsave is disabled Date: Fri, 20 May 2011 08:08:59 +0100 Message-ID: <4DD62FAB02000078000425C3@vpn.id2.novell.com> References: <4DD3B3370200007800041DB6@vpn.id2.novell.com> <4DD433C5.4060208@amd.com> <4DD4D91D02000078000420BF@vpn.id2.novell.com> <4DD538A2.7050801@amd.com> <4DD55BF402000078000422E8@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Wei Huang2 Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org >>> On 19.05.11 at 18:08, "Huang2, Wei" wrote: > That is right. Could you slip it into your patch and I can sign it off? = Or I=20 > 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 >=20 > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@novell.com]=20 > 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=20 > when xsave is disabled >=20 >>>> On 19.05.11 at 17:34, Wei Huang wrote: >> I misunderstood your email then. Doesn't your patch already achieve = this=20 >> objective? We didn't check sub-leaf ID (ECX) in switch-case statement.= =20 >> So all sub-leaves will be cleaned out by your patch. >=20 > 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). >=20 > Jan >=20 >> -Wei >>=20 >> On 05/19/2011 01:47 AM, Jan Beulich wrote: >>>>>> On 18.05.11 at 23:01, Wei Huang 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=3D0x00000000 ebx=3D0x00000000 ecx=3D0x000000= 00 >>>> edx=3D0x00000000 >>>> 0x0000000d 0x00: eax=3D0x00000003 ebx=3D0x00000240 ecx=3D0x000002= 40 >>>> edx=3D0x00000000 >>>> 0x0000000d 0x02: eax=3D0x00000000 ebx=3D0x00000000 ecx=3D0x000000= 00 >>>> edx=3D0x00000000 >>>> 0x0000000d 0x3e: eax=3D0x00000000 ebx=3D0x00000000 ecx=3D0x000000= 00 >>>> edx=3D0x00000000 >>>> >>>> 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 >>>>> >>>>> --- 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 */ >>>>> >>>>> >>>>> >>> >>> >>>