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:33:05 +0000 Message-ID: References: <1327063527.30054.37.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: <1327063527.30054.37.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 , Dietmar Hahn Cc: Wei Wang , "xen-devel@lists.xensource.com" , Haitao Shan List-Id: xen-devel@lists.xenproject.org On 20/01/2012 12:45, "Ian Campbell" wrote: >>> It's obviously an option of fairly narrow interest. If someone tries to >>> enable the per-domain option on a CPU which has problems, you can fail the >>> domain creation, or print a warning in the hypervisor log, or whatever. Any >>> sensible option in that respect is fine by me! >> >> What is the best solution for this? >> A domain specific configuration option is needed (vpmu?) which is usable in >> libxc/xc_cpuid_x86.c to select/deselect special vpmu bits in the cpuid >> command. >> Can you point me to an proper example? > > Can't this already be done via the cpuid domain option given the correct > runes? Maybe with an addition to the table in libxl_cpuid_parse_config? 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. -- Keir