From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dietmar Hahn Subject: Re: [PATCH 2 of 2] vpmu: Add a vpmu cpuid function Date: Fri, 20 Jan 2012 15:08:02 +0100 Message-ID: <10623458.xWNmoTWpXQ@amur> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Wei Wang , "xen-devel@lists.xensource.com" , Haitao Shan , Ian Campbell List-Id: xen-devel@lists.xenproject.org Am Freitag 20 Januar 2012, 13:47:24 schrieb Keir Fraser: > 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. Thanks for the hints. For the first time I'll go through the source and try to understand what you are talking about. Dietmar.