Xen devel - Jul 2008 - [PATCH]: Add support for Intel CPUID Feature mask in Xen

Hi, all
Some Latest Intel CPU models (CPUID.1.EAX >= 0x00010674) support cupid
mask features. Cpuid feature mask is used to limit the feature flags
reported by CPUID.1.EDX:ECX.

This small patch adds CPUID feature mask support in XEN by adding boot
options in Grub entry as below example:
kernel /boot/xen.gz com1=115200,8n1 console=com1 cpuid_mask_ecx 0xFFFF7FFF
cpuid_mask_edx = 0xFFFFFFFC

For detailed usage information, please refer to the attached document:
cupid_feature_mask.txt.

Thanks& Regards,
Criping



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

> Hi, all
> Some Latest Intel CPU models (CPUID.1.EAX >= 0x00010674) support cupid
> mask features. Cpuid feature mask is used to limit the feature flags
> reported by CPUID.1.EDX:ECX.
> 
> This small patch adds CPUID feature mask support in XEN by adding boot
> options in Grub entry as below example:
> kernel /boot/xen.gz com1=115200,8n1 console=com1 cpuid_mask_ecx >
0xFFFF7FFF cpuid_mask_edx = 0xFFFFFFFC
> 
> For detailed usage information, please refer to the attached document:
> cupid_feature_mask.txt.
It''s good to see this feature enabled, but it would be a lot more user
friendly if the patch took a cpu family and model number and then
''flattened'' the cpuid back to the specification of that CPU.
We don''t
need to go back very far (certainly not pre-VT), and I''d be happy if we
just did all core2 (and newer) CPUs.

Also, is there a magic MSR to change the CPU family/model number
reported? It would make sense to do this too.

At what point does the CPU masking occur? Ideally we''d do it just
before
starting dom0. [Actually, we might want to be able to invoke it from
libxc in future too]

Ian  

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

Hi, Ian
See comments below:
Thanks& Regards,
Criping

Ian Pratt wrote:
>> Hi, all
>> Some Latest Intel CPU models (CPUID.1.EAX >= 0x00010674) support
>> cupid mask features. Cpuid feature mask is used to limit the feature
>> flags reported by CPUID.1.EDX:ECX. 
>> 
>> This small patch adds CPUID feature mask support in XEN by adding
>> boot options in Grub entry as below example:
>> kernel /boot/xen.gz com1=115200,8n1 console=com1 cpuid_mask_ecx
>> 0xFFFF7FFF cpuid_mask_edx = 0xFFFFFFFC
>> 
>> For detailed usage information, please refer to the attached
>> document: cupid_feature_mask.txt.
> 
> It''s good to see this feature enabled, but it would be a lot more
user
> friendly if the patch took a cpu family and model number and then
> ''flattened'' the cpuid back to the specification of that
CPU. We don''t
> need to go back very far (certainly not pre-VT), and I''d be happy
if
> we just did all core2 (and newer) CPUs.
> 
We also hesitate how to solve it for some time. Yet we found since cpu 
models are quite much even from core2, finding each of them is not that easy
(cpuid.1.ECX:EDX might only could be referred in corresponding BIOS guide). 

Also, if using one older type that we did not cover, then there''s some
problem.
What''s more, ecx/edx only give few features that  users might do care. 
So maybe users should know by themselves on how to set the few bits 
to 0 and passes others just 1.

So we decided just give the mask and give users detailed docs help?
> Also, is there a magic MSR to change the CPU family/model number
> reported? It would make sense to do this too.
Oh, No, there are no such magic MSR. Only cpuid.1.ECX:EDX could be masked.
> 
> At what point does the CPU masking occur? Ideally we''d do it just
> before starting dom0. [Actually, we might want to be able to invoke
> it from libxc in future too]
When setting cpuid_mask, both HV and all domains will all be cheated from this
point, it is a hardware and-logic .
So for consistency, we set the msr from xen start time after detecting cpu. 
Seems setting@xen startup Or setting@domain0 startup 
will not make a big difference here?

At earlier code, we add switch code when doing domain scheduling, 
only those pv_guest(also apps) who defines this cpuid_mask will be cheated. 
When domain0/HV is scheduled, we Will reset cpuid_mask back to 0xFFFFFFFF. 
But later we thought this price is too big and Code is not clean, so we give it
up.
> 
> Ian

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

> > It''s good to see this feature enabled, but it would be a lot
more
user
> > friendly if the patch took a cpu family and model number and then
> > ''flattened'' the cpuid back to the specification of
that CPU. We
don''t
> > need to go back very far (certainly not pre-VT), and I''d be
happy if
> > we just did all core2 (and newer) CPUs.
> >
> We also hesitate how to solve it for some time. Yet we found since cpu
> models are quite much even from core2, finding each of them is not
that
> easy
> (cpuid.1.ECX:EDX might only could be referred in corresponding BIOS
> guide).
>
> Also, if using one older type that we did not cover, then there''s
some
> problem.
> What''s more, ecx/edx only give few features that  users might do
care.
> So maybe users should know by themselves on how to set the few bits
> to 0 and passes others just 1.
Well, if someone from Intel can''t figure it out what hope have users
got!

I think it would be much better if we cooked this to a family/model
number.
> > Also, is there a magic MSR to change the CPU family/model number
> > reported? It would make sense to do this too.
> Oh, No, there are no such magic MSR. Only cpuid.1.ECX:EDX could be
> masked.
That''s a shame. Are you 100% sure? I know it''s possible for
the BIOS to
configure MSRs to hide certain differences, because I''ve seen two CPUs
with different steppings get levelled to the same (older) stepping by a
BIOS upgrade.
> > At what point does the CPU masking occur? Ideally we''d do it
just
> > before starting dom0. [Actually, we might want to be able to invoke
> > it from libxc in future too]
> When setting cpuid_mask, both HV and all domains will all be cheated
> from this
> point, it is a hardware and-logic .
> So for consistency, we set the msr from xen start time after detecting
> cpu.
> Seems setting@xen startup Or setting@domain0 startup
> will not make a big difference here?
That''s not necessarily the case -- we may want Xen to use features that
we hide from guests.
 
Ian


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