WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Andre Przywara <andre.przywara@xxxxxxx>
Subject: [Xen-devel] Re: [PATCH 0/2] [RFC] xl: add cpuid config file option
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Mon, 30 Aug 2010 14:21:19 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Mon, 30 Aug 2010 06:21:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C77B5EE.2050403@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4C77B5EE.2050403@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>