From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v2 2/3] x86/AMD: support further feature masking MSRs Date: Tue, 08 Apr 2014 11:14:29 -0400 Message-ID: <53441255.1070908@oracle.com> References: <53428DCC020000780000607D@nat28.tlf.novell.com> <53428F4402000078000060BB@nat28.tlf.novell.com> <5342C28C.2090809@oracle.com> <5343BE3B020000780000668A@nat28.tlf.novell.com> <5343FEBB.7090202@oracle.com> <53441D840200007800006ACE@nat28.tlf.novell.com> <53440448.5020300@oracle.com> <534424CE0200007800006BBD@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WXXgU-0004z7-Ey for xen-devel@lists.xenproject.org; Tue, 08 Apr 2014 15:11:34 +0000 In-Reply-To: <534424CE0200007800006BBD@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , Keir Fraser , Aravind Gopalakrishnan , suravee.suthikulpanit@amd.com List-Id: xen-devel@lists.xenproject.org On 04/08/2014 10:33 AM, Jan Beulich wrote: >>>> On 08.04.14 at 16:14, wrote: >> On 04/08/2014 10:02 AM, Jan Beulich wrote: >>>>>> On 08.04.14 at 15:50, wrote: >>>> On 04/08/2014 03:15 AM, Jan Beulich wrote: >>>>>>>> On 07.04.14 at 17:21, wrote: >>>>>> On 04/07/2014 05:43 AM, Jan Beulich wrote: >>>>>> >>>>>> @@ -179,11 +196,39 @@ static void __devinit set_cpuidmask(cons >>>>>> printk("Writing CPUID extended feature mask ECX:EDX -> %08Xh:%08Xh\n", >>>>>> extfeat_ecx, extfeat_edx); >>>>>> >>>>>> + if (c->cpuid_level >= 7) >>>>>> + cpuid_count(7, 0, &eax, &ebx, &ecx, &edx); >>>>>> + else >>>>>> + ebx = eax = 0; >>>>>> + if ((eax | ebx) && ~(l7s0_eax & l7s0_ebx)) { >>>>>> + if (l7s0_eax > eax) >>>>>> + l7s0_eax = eax; >>>>>> + l7s0_ebx &= ebx; >>>>>> >>>>>> >>>>>> Can you explain why eax is treated differently here (i.e. not ANDing it >>>>>> as is done with ebx)? >>>>> Generally I think code like this implies that you know the specification: >>>>> eax here represents the maximum supported subleaf, and hence >>>>> needs to be limited rather than masked. >>>> All specs that I have say that bits of CPUID Fn0000_0007_EAX_x0 are >>>> reserved. >>> Intel's SDM Vol 2 rev 49 (325383-049US) says "07H Sub-leaf 0 (Input >>> ECX = 0). EAX Bits 31-00: Reports the maximum input value for >>> supported leaf 7 sub-leaves." Not sure what other specs you might >>> be looking at. >> This is a patch to xen/arch/x86/cpu/amd.c so I was looking at AMD's >> BKDGs. Why is Intel's definition relevant here? > Because leaf 7 is (largely) Intel-defined (AMD adds their extensions > usually at leaves 800000xx). I don't know whether we can assume that AMD will follow the same definitions. They usually try not to deliberately do something differently there but this is never guaranteed. -boris