Xen devel - Aug 2010 - [PATCH 0/2] [RFC] xl: add cpuid config file option

Hi,

xl is currently ignoring the cpuid= variable in the config file. As I
don''t like the current interface xm exposes (basically because it is
complicated, unintuitive and very error prone), I implemented a new
scheme for specifying CPUID flags policy, combining QEMU''s and
Xen''s
approach:
cpuid = "<base>,<feature_name>=[01xks]*,...
The patch includes a (preliminary) list of feature names along with
their bit positions. The value for each feature bit copies the current
meaning is Xen:
0: clear, 1: set, x: don''t care/use default, k: keep from host, s: use
host but preserve across migration
The value can also be a number (either in hex or decimal), so things
like "stepping=3" can be easily specified.
To show you the advantage, I quote the example config
file:
> #cpuid=[ ''1:ecx=xxxxxxxxxxx00xxxxxxxxxxxxxxxxxxx,
> #           eax=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'' ]
> # - Unset the SSE4 features (CPUID.1[ECX][20-19])
> # - Default behaviour for all other bits in ECX And EAX registers.
new version: cpuid = "host,sse4.1=0,sse4.2=0"
> #   Expose to the guest multi-core cpu instead of multiple processors
> # Example for intel, expose a 8-core processor :
> #cpuid=[''1:edx=xxx1xxxxxxxxxxxxxxxxxxxxxxxxxxxx,
> #          ebx=xxxxxxxx00010000xxxxxxxxxxxxxxxx'',
> #     ''4,0:eax=001111xxxxxxxxxxxxxxxxxxxxxxxxxx'']
> #  - CPUID.1[EDX][HT] : Enable HT
> #  - CPUID.1[EBX] : Number of vcpus * 2
> #  - CPUID.4,0[EAX] : Number of vcpus * 2 - 1
> #vcpus=8
new version: cpuid =
"host,htt=1,proccount=16,maxcores=15"
> # Example for amd, expose a 5-core processor :
> # cpuid = [''1:ebx=xxxxxxxx00001010xxxxxxxxxxxxxxxx,
> #             edx=xxx1xxxxxxxxxxxxxxxxxxxxxxxxxxxx'',
> # ''0x80000001:ecx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1x'',
> # ''0x80000008:ecx=xxxxxxxxxxxxxxxxxxxxxxxxxx001001'']
> #   - CPUID.1[EBX] : Threads per Core * Cores per Socket (2 * #vcpus)
> #   - CPUID.1[EDX][HT] : Enable HT
> #   - CPUID.0x80000001[CmpLegacy] : Use legacy method
> #   - CPUID.0x80000008[ECX] : #vcpus * 2 - 1
new version: cpuid="host,htt=1,cmplegacy=1,proccount=10,nc=9"

The parse_cpuid function in xl_cmdimpl.c parses the string and
translates it into the interface used by libxc.

If backward compatibility to the xm version is needed, I could also add
a quirk for the old interface. Since it uses a Python list, this can be
intercepted early in xl''s parsing process and could use a compat code
path.

This first version works for me, I''d like to hear your comments.

Regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12


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

On Fri, 27 Aug 2010, Andre Przywara wrote:
> Hi,
> 
> xl is currently ignoring the cpuid= variable in the config file. As I
> don''t like the current interface xm exposes (basically because it
is
> complicated, unintuitive and very error prone), I implemented a new
> scheme for specifying CPUID flags policy, combining QEMU''s and
Xen''s
> approach:
> cpuid = "<base>,<feature_name>=[01xks]*,...
> The patch includes a (preliminary) list of feature names along with
> their bit positions. The value for each feature bit copies the current
> meaning is Xen:
> 0: clear, 1: set, x: don''t care/use default, k: keep from host, s:
use
> host but preserve across migration
> The value can also be a number (either in hex or decimal), so things
> like "stepping=3" can be easily specified.
> To show you the advantage, I quote the example config file:
> > #cpuid=[ ''1:ecx=xxxxxxxxxxx00xxxxxxxxxxxxxxxxxxx,
> > #           eax=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'' ]
> > # - Unset the SSE4 features (CPUID.1[ECX][20-19])
> > # - Default behaviour for all other bits in ECX And EAX registers.
> new version: cpuid = "host,sse4.1=0,sse4.2=0"
> > #   Expose to the guest multi-core cpu instead of multiple processors
> > # Example for intel, expose a 8-core processor :
> > #cpuid=[''1:edx=xxx1xxxxxxxxxxxxxxxxxxxxxxxxxxxx,
> > #          ebx=xxxxxxxx00010000xxxxxxxxxxxxxxxx'',
> > #     ''4,0:eax=001111xxxxxxxxxxxxxxxxxxxxxxxxxx'']
> > #  - CPUID.1[EDX][HT] : Enable HT
> > #  - CPUID.1[EBX] : Number of vcpus * 2
> > #  - CPUID.4,0[EAX] : Number of vcpus * 2 - 1
> > #vcpus=8
> new version: cpuid = "host,htt=1,proccount=16,maxcores=15"
> > # Example for amd, expose a 5-core processor :
> > # cpuid = [''1:ebx=xxxxxxxx00001010xxxxxxxxxxxxxxxx,
> > #             edx=xxx1xxxxxxxxxxxxxxxxxxxxxxxxxxxx'',
> > # ''0x80000001:ecx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1x'',
> > # ''0x80000008:ecx=xxxxxxxxxxxxxxxxxxxxxxxxxx001001'']
> > #   - CPUID.1[EBX] : Threads per Core * Cores per Socket (2 * #vcpus)
> > #   - CPUID.1[EDX][HT] : Enable HT
> > #   - CPUID.0x80000001[CmpLegacy] : Use legacy method
> > #   - CPUID.0x80000008[ECX] : #vcpus * 2 - 1
> new version: cpuid="host,htt=1,cmplegacy=1,proccount=10,nc=9"
> 
> The parse_cpuid function in xl_cmdimpl.c parses the string and
> translates it into the interface used by libxc.
> 
> If backward compatibility to the xm version is needed, I could also add
> a quirk for the old interface. Since it uses a Python list, this can be
> intercepted early in xl''s parsing process and could use a compat
code path.
> 
> This first version works for me, I''d like to hear your comments.
> 
I like your approach. Ian, what do you think?
We would still need another parser for backward compatibility though.
Also I think that parse_cpuid belongs to libxl instead of xl.


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

Stefano Stabellini writes ("[Xen-devel] Re: [PATCH 0/2] [RFC] xl: add cpuid
config file option"):
> On Fri, 27 Aug 2010, Andre Przywara wrote:
> > This first version works for me, I''d like to hear your
comments.
> I like your approach. Ian, what do you think?
I think this is a nice approach.  But there didn''t seem to be a patch
attached to your mail ? :-)
> We would still need another parser for backward compatibility
> though.
Is it possible to distinguish the old xend syntax and so have libxl
handle either ?  I''m not familiar with the xend cpuid syntax.
> Also I think that parse_cpuid belongs to libxl instead of xl.
Yes.

Ian.

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

Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] Re: [PATCH 0/2] [RFC] xl: add
cpuid config file option"):
>> On Fri, 27 Aug 2010, Andre Przywara wrote:
>>> This first version works for me, I''d like to hear your
comments.
>> I like your approach. Ian, what do you think?
> 
> I think this is a nice approach.  But there didn''t seem to be a
patch
> attached to your mail ? :-)
> 
>> We would still need another parser for backward compatibility
>> though.
> 
> Is it possible to distinguish the old xend syntax and so have libxl
> handle either ?  I''m not familiar with the xend cpuid syntax.
xm uses a Python list syntax, so this looks different. It is possible to 
tell them apart: Currently you can check the return value of 
xlu_cfg_get_list() to try the new approach otherwise, but this prints an 
ugly warning to the console. So I created a (silent) get_type function 
to check it before calling the respective functions.
The prototype works already, I will test and polish and then send out a 
second version later.
> 
>> Also I think that parse_cpuid belongs to libxl instead of xl.
> 
> Yes.
You are right, I have already moved it (in v2).

Regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12


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