[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function

On Fri, 2012-01-20 at 13:33 +0000, Keir Fraser wrote:
> On 20/01/2012 12:45, "Ian Campbell" <Ian.Campbell@xxxxxxxxxx> 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.

Plus a bunch of ad-hoc stuff which predates the cpuid bit-fiddling
support but is reflected in the cpuid (pae, apic, acpi etc).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.