From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 2 of 2] vpmu: Add a vpmu cpuid function Date: Fri, 20 Jan 2012 13:47:24 +0000 Message-ID: References: <1327066657.30054.45.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1327066657.30054.45.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: Wei Wang , "xen-devel@lists.xensource.com" , Haitao Shan , Dietmar Hahn List-Id: xen-devel@lists.xenproject.org On 20/01/2012 13:37, "Ian Campbell" wrote: >> Yes that's probably the way to do it. If the resulting required >> configuration runes are too cryptic or vendor-specific, it may make sense to >> have the libxl cpuid logic consume a 'vpmu' option which it then turns into >> a set of lower-level cpuid settings to eventually pass down to the code in >> libxc/xc_cpuid. >> >> It's a trifle messy I will admit. Arguably the 'default policy' bits of >> xc_cpuid_x86.c would better belong in libxl these days, where we would have >> better access to a domain's configuration state. As it is, we may end up >> with a spread of default policy across Xen (for dom0), libxc, and libxl. > > Plus a bunch of ad-hoc stuff which predates the cpuid bit-fiddling > support but is reflected in the cpuid (pae, apic, acpi etc). Well, this is done in libxc now, so I think I included it in my list. ;) But it would be cleaner done in libxl. I don't think anyone will be straining their arm to volunteer for this cleanup, but we shouldn't be shy about putting new policy stuff in libxl if it makes best sense to put it there. -- Keir