Xen devel - Jul 2012 - [PATCH] xen/x86: Add support for cpuid masking on Intel Xeon Processor E5 Family

Although the "Intel Virtualization Technology FlexMigration
Application Note" (http://www.intel.com/Assets/PDF/manual/323850.pdf)
does not document support for extended model 2H model DH (Intel Xeon
Processor E5 Family), empirical evidence shows that the same MSR
addresses can be used for cpuid masking as exdended model 2H model AH
(Intel Xen Processor E3-1200 Family).

Signed-off-by: Matt Wilson <msw@amazon.com>

diff -r e6266fc76d08 -r bf922651da96 xen/arch/x86/cpu/intel.c
--- a/xen/arch/x86/cpu/intel.c	Fri Jul 27 12:22:13 2012 +0200
+++ b/xen/arch/x86/cpu/intel.c	Sat Jul 28 17:27:30 2012 +0000
@@ -104,7 +104,7 @@ static void __devinit set_cpuidmask(cons
 			return;
 		extra = "xsave ";
 		break;
-	case 0x2a:
+	case 0x2a: case 0x2d:
 		wrmsr(MSR_INTEL_CPUID1_FEATURE_MASK_V2,
 		      opt_cpuid_mask_ecx,
 		      opt_cpuid_mask_edx);

>>> On 28.07.12 at 21:19, Matt Wilson <msw@amazon.com> wrote:
> Although the "Intel Virtualization Technology FlexMigration
> Application Note" (http://www.intel.com/Assets/PDF/manual/323850.pdf)
> does not document support for extended model 2H model DH (Intel Xeon
> Processor E5 Family), empirical evidence shows that the same MSR
> addresses can be used for cpuid masking as exdended model 2H model AH
> (Intel Xen Processor E3-1200 Family).
Empirical evidence isn''t really enough - let''s have someone at
Intel
confirm this - Jun, Don?

Jan
> Signed-off-by: Matt Wilson <msw@amazon.com>
> 
> diff -r e6266fc76d08 -r bf922651da96 xen/arch/x86/cpu/intel.c
> --- a/xen/arch/x86/cpu/intel.c	Fri Jul 27 12:22:13 2012 +0200
> +++ b/xen/arch/x86/cpu/intel.c	Sat Jul 28 17:27:30 2012 +0000
> @@ -104,7 +104,7 @@ static void __devinit set_cpuidmask(cons
>  			return;
>  		extra = "xsave ";
>  		break;
> -	case 0x2a:
> +	case 0x2a: case 0x2d:
>  		wrmsr(MSR_INTEL_CPUID1_FEATURE_MASK_V2,
>  		      opt_cpuid_mask_ecx,
>  		      opt_cpuid_mask_edx);

IMO, it''s risky since it''s not architecturally committed.
Only processor family 6 w/ 0x17, 0x1d, 0x1a, 0x1e, 0x1f, 0x25, 0x2c, 0x2e, 0x2f,
0x2a are *architecturally* supported.

Thanks,
Jinsong

Matt Wilson wrote:
> Although the "Intel Virtualization Technology FlexMigration
> Application Note" (http://www.intel.com/Assets/PDF/manual/323850.pdf)
> does not document support for extended model 2H model DH (Intel Xeon
> Processor E5 Family), empirical evidence shows that the same MSR
> addresses can be used for cpuid masking as exdended model 2H model AH
> (Intel Xen Processor E3-1200 Family).
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>
> 
> diff -r e6266fc76d08 -r bf922651da96 xen/arch/x86/cpu/intel.c
> --- a/xen/arch/x86/cpu/intel.c	Fri Jul 27 12:22:13 2012 +0200
> +++ b/xen/arch/x86/cpu/intel.c	Sat Jul 28 17:27:30 2012 +0000
> @@ -104,7 +104,7 @@ static void __devinit set_cpuidmask(cons
>  			return;
>  		extra = "xsave ";
>  		break;
> -	case 0x2a:
> +	case 0x2a: case 0x2d:
>  		wrmsr(MSR_INTEL_CPUID1_FEATURE_MASK_V2,
>  		      opt_cpuid_mask_ecx,
>  		      opt_cpuid_mask_edx);

On Sun, Jul 29, 2012 at 11:57 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >>> On 28.07.12 at 21:19, Matt Wilson <msw@amazon.com>
wrote:
> > Although the "Intel Virtualization Technology FlexMigration
> > Application Note"
(http://www.intel.com/Assets/PDF/manual/323850.pdf)
> > does not document support for extended model 2H model DH (Intel Xeon
> > Processor E5 Family), empirical evidence shows that the same MSR
> > addresses can be used for cpuid masking as exdended model 2H model AH
> > (Intel Xen Processor E3-1200 Family).
>
> Empirical evidence isn''t really enough - let''s have
someone at Intel
> confirm this - Jun, Don?
>
Thanks for the patch. The patch looks good, and it should be in.
We''ll update the document.


>
> Jan
>
> > Signed-off-by: Matt Wilson <msw@amazon.com>
> >
> > diff -r e6266fc76d08 -r bf922651da96 xen/arch/x86/cpu/intel.c
> > --- a/xen/arch/x86/cpu/intel.c        Fri Jul 27 12:22:13 2012 +0200
> > +++ b/xen/arch/x86/cpu/intel.c        Sat Jul 28 17:27:30 2012 +0000
> > @@ -104,7 +104,7 @@ static void __devinit set_cpuidmask(cons
> >                       return;
> >               extra = "xsave ";
> >               break;
> > -     case 0x2a:
> > +     case 0x2a: case 0x2d:
> >               wrmsr(MSR_INTEL_CPUID1_FEATURE_MASK_V2,
> >                     opt_cpuid_mask_ecx,
> >                     opt_cpuid_mask_edx);
>
>
>
>

-- 
Jun
Intel Open Source Technology Center


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

>>> On 06.08.12 at 22:23, "Nakajima, Jun"
<jun.nakajima@intel.com> wrote:
> On Sun, Jul 29, 2012 at 11:57 PM, Jan Beulich <JBeulich@suse.com>
wrote:
> 
>> >>> On 28.07.12 at 21:19, Matt Wilson <msw@amazon.com>
wrote:
>> > Although the "Intel Virtualization Technology FlexMigration
>> > Application Note"
(http://www.intel.com/Assets/PDF/manual/323850.pdf)
>> > does not document support for extended model 2H model DH (Intel
Xeon
>> > Processor E5 Family), empirical evidence shows that the same MSR
>> > addresses can be used for cpuid masking as exdended model 2H model
AH
>> > (Intel Xen Processor E3-1200 Family).
>>
>> Empirical evidence isn''t really enough - let''s have
someone at Intel
>> confirm this - Jun, Don?
>>
> 
> Thanks for the patch. The patch looks good, and it should be in.
> We''ll update the document.
I take this as an ack then, and will commit it that way.

Jan
>> > Signed-off-by: Matt Wilson <msw@amazon.com>
>> >
>> > diff -r e6266fc76d08 -r bf922651da96 xen/arch/x86/cpu/intel.c
>> > --- a/xen/arch/x86/cpu/intel.c        Fri Jul 27 12:22:13 2012
+0200
>> > +++ b/xen/arch/x86/cpu/intel.c        Sat Jul 28 17:27:30 2012
+0000
>> > @@ -104,7 +104,7 @@ static void __devinit set_cpuidmask(cons
>> >                       return;
>> >               extra = "xsave ";
>> >               break;
>> > -     case 0x2a:
>> > +     case 0x2a: case 0x2d:
>> >               wrmsr(MSR_INTEL_CPUID1_FEATURE_MASK_V2,
>> >                     opt_cpuid_mask_ecx,
>> >                     opt_cpuid_mask_edx);
>>
>>
>>
>>
> 
> 
> -- 
> Jun
> Intel Open Source Technology Center

On Mon, Aug 06, 2012 at 11:49:12PM -0700, Jan Beulich
wrote:
> >>> On 06.08.12 at 22:23, "Nakajima, Jun"
<jun.nakajima@intel.com> wrote:
> > On Sun, Jul 29, 2012 at 11:57 PM, Jan Beulich
<JBeulich@suse.com> wrote:
> > 
> >> >>> On 28.07.12 at 21:19, Matt Wilson
<msw@amazon.com> wrote:
> >> > Although the "Intel Virtualization Technology
FlexMigration
> >> > Application Note"
(http://www.intel.com/Assets/PDF/manual/323850.pdf)
> >> > does not document support for extended model 2H model DH
(Intel Xeon
> >> > Processor E5 Family), empirical evidence shows that the same
MSR
> >> > addresses can be used for cpuid masking as exdended model 2H
model AH
> >> > (Intel Xen Processor E3-1200 Family).
> >>
> >> Empirical evidence isn''t really enough - let''s
have someone at Intel
> >> confirm this - Jun, Don?
> >>
> > 
> > Thanks for the patch. The patch looks good, and it should be in.
> > We''ll update the document.
> 
> I take this as an ack then, and will commit it that way.
Thanks for committing, Jan.

For what it''s worth, I think that the first line of the commit log got
dropped, which makes for a strange short log message of:

  Although the "Intel Virtualization Technology FlexMigration

Matt
> >> > Signed-off-by: Matt Wilson <msw@amazon.com>
> >> >
> >> > diff -r e6266fc76d08 -r bf922651da96 xen/arch/x86/cpu/intel.c
> >> > --- a/xen/arch/x86/cpu/intel.c        Fri Jul 27 12:22:13
2012 +0200
> >> > +++ b/xen/arch/x86/cpu/intel.c        Sat Jul 28 17:27:30
2012 +0000
> >> > @@ -104,7 +104,7 @@ static void __devinit set_cpuidmask(cons
> >> >                       return;
> >> >               extra = "xsave ";
> >> >               break;
> >> > -     case 0x2a:
> >> > +     case 0x2a: case 0x2d:
> >> >               wrmsr(MSR_INTEL_CPUID1_FEATURE_MASK_V2,
> >> >                     opt_cpuid_mask_ecx,
> >> >                     opt_cpuid_mask_edx);
> >>
> >>
> >>
> >>
> > 
> > 
> 
>

>>> On 07.08.12 at 19:47, Matt Wilson <msw@amazon.com> wrote:
> For what it''s worth, I think that the first line of the commit log
got
> dropped, which makes for a strange short log message of:
> 
>   Although the "Intel Virtualization Technology FlexMigration
Yes, I''m sorry for that, but I realized this only after pushing, and
I''m unaware of ways to adjust the commit message of an existing
c/s.

Jan

On Wed, 2012-08-08 at 08:08 +0100, Jan Beulich wrote:
> >>> On 07.08.12 at 19:47, Matt Wilson <msw@amazon.com>
wrote:
> > For what it''s worth, I think that the first line of the
commit log got
> > dropped, which makes for a strange short log message of:
> > 
> >   Although the "Intel Virtualization Technology FlexMigration
> 
> Yes, I''m sorry for that, but I realized this only after pushing,
and
> I''m unaware of ways to adjust the commit message of an existing
> c/s.
There is an hg rebase extension something like git''s rebase -i but I
find the easiest way is to use the mq extension''s function which pulls
the tip commit into a patch in the queue.

Actually, that''s not quite true, I find the real easiest way is to hg
strip the wrong commit and try again.

Actually, that''s not true either, the real easiest way IMHO is to use a
git mirror for all the leg work and Ian J''s git2hgapply script to
actually "apply" it. YMMV depending on your feelings about git
though ;-)

Ian.

>>> On 08.08.12 at 10:02, Ian Campbell <Ian.Campbell@citrix.com>
wrote:
> On Wed, 2012-08-08 at 08:08 +0100, Jan Beulich wrote:
>> >>> On 07.08.12 at 19:47, Matt Wilson <msw@amazon.com>
wrote:
>> > For what it''s worth, I think that the first line of the
commit log got
>> > dropped, which makes for a strange short log message of:
>> > 
>> >   Although the "Intel Virtualization Technology FlexMigration
>> 
>> Yes, I''m sorry for that, but I realized this only after
pushing, and
>> I''m unaware of ways to adjust the commit message of an
existing
>> c/s.
> 
> There is an hg rebase extension something like git''s rebase -i but
I
> find the easiest way is to use the mq extension''s function which
pulls
> the tip commit into a patch in the queue.
> 
> Actually, that''s not quite true, I find the real easiest way is to
hg
> strip the wrong commit and try again.
But that''s only if it didn''t get pushed yet?
> Actually, that''s not true either, the real easiest way IMHO is to
use a
> git mirror for all the leg work and Ian J''s git2hgapply script to
> actually "apply" it. YMMV depending on your feelings about git
> though ;-)
Indeed. While I''m slowly getting to know it better, I''m still
not
really friends with it.

Jan

On Wed, 2012-08-08 at 09:48 +0100, Jan Beulich wrote:
> >>> On 08.08.12 at 10:02, Ian Campbell
<Ian.Campbell@citrix.com> wrote:
> > On Wed, 2012-08-08 at 08:08 +0100, Jan Beulich wrote:
> >> >>> On 07.08.12 at 19:47, Matt Wilson
<msw@amazon.com> wrote:
> >> > For what it''s worth, I think that the first line of
the commit log got
> >> > dropped, which makes for a strange short log message of:
> >> > 
> >> >   Although the "Intel Virtualization Technology
FlexMigration
> >> 
> >> Yes, I''m sorry for that, but I realized this only after
pushing, and
> >> I''m unaware of ways to adjust the commit message of an
existing
> >> c/s.
> > 
> > There is an hg rebase extension something like git''s rebase
-i but I
> > find the easiest way is to use the mq extension''s function
which pulls
> > the tip commit into a patch in the queue.
> > 
> > Actually, that''s not quite true, I find the real easiest way
is to hg
> > strip the wrong commit and try again.
> 
> But that''s only if it didn''t get pushed yet?
Yes, it''s only if you catch the mistake before pushing. If
you''ve pushed
then in principal you could hg strip on the server but in practice you
don''t want to do that on a widely used/shared repo and you just have to
live with the mistake, or I suppose you could hg revert and recommit if
the bad cset was really confusing etc.
> > Actually, that''s not true either, the real easiest way IMHO
is to use a
> > git mirror for all the leg work and Ian J''s git2hgapply
script to
> > actually "apply" it. YMMV depending on your feelings about
git
> > though ;-)
> 
> Indeed. While I''m slowly getting to know it better, I''m
still not
> really friends with it.
I''m not sure any one is ;-)

Ian.

Jan-

If we''re using git doesn''t `git -amend'' do what you
want?  If we''re talking `hg'' then I have no clue.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786


-----Original Message-----
From: Jan Beulich [mailto:JBeulich@suse.com] 
Sent: Wednesday, August 08, 2012 2:48 AM
To: Ian Campbell
Cc: Matt Wilson; Dugger, Donald D; Liu, Jinsong; Nakajima, Jun;
xen-devel@lists.xen.org; Keir(Xen.org)
Subject: Re: [Xen-devel] [PATCH] xen/x86: Add support for cpuid masking on Intel
Xeon Processor E5 Family
>>> On 08.08.12 at 10:02, Ian Campbell <Ian.Campbell@citrix.com>
wrote:
> On Wed, 2012-08-08 at 08:08 +0100, Jan Beulich wrote:
>> >>> On 07.08.12 at 19:47, Matt Wilson <msw@amazon.com>
wrote:
>> > For what it''s worth, I think that the first line of the
commit log got
>> > dropped, which makes for a strange short log message of:
>> > 
>> >   Although the "Intel Virtualization Technology FlexMigration
>> 
>> Yes, I''m sorry for that, but I realized this only after
pushing, and
>> I''m unaware of ways to adjust the commit message of an
existing
>> c/s.
> 
> There is an hg rebase extension something like git''s rebase -i but
I
> find the easiest way is to use the mq extension''s function which
pulls
> the tip commit into a patch in the queue.
> 
> Actually, that''s not quite true, I find the real easiest way is to
hg
> strip the wrong commit and try again.
But that''s only if it didn''t get pushed yet?
> Actually, that''s not true either, the real easiest way IMHO is to
use a
> git mirror for all the leg work and Ian J''s git2hgapply script to
> actually "apply" it. YMMV depending on your feelings about git
> though ;-)
Indeed. While I''m slowly getting to know it better, I''m still
not
really friends with it.

Jan