From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Wei Wang <wei.wang2@amd.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Haitao Shan <haitao.shan@intel.com>,
Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Subject: Re: [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
Date: Fri, 20 Jan 2012 13:47:24 +0000 [thread overview]
Message-ID: <CB3F20EC.293DD%keir.xen@gmail.com> (raw)
In-Reply-To: <1327066657.30054.45.camel@zakaz.uk.xensource.com>
On 20/01/2012 13:37, "Ian Campbell" <Ian.Campbell@citrix.com> 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
next prev parent reply other threads:[~2012-01-20 13:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-19 13:54 [PATCH 2 of 2] vpmu: Add a vpmu cpuid function Dietmar Hahn
2012-01-20 10:29 ` Keir Fraser
2012-01-20 10:49 ` Dietmar Hahn
2012-01-20 10:54 ` Keir Fraser
2012-01-20 12:40 ` Dietmar Hahn
2012-01-20 12:45 ` Ian Campbell
2012-01-20 13:33 ` Keir Fraser
2012-01-20 13:37 ` Ian Campbell
2012-01-20 13:47 ` Keir Fraser [this message]
2012-01-20 14:08 ` Dietmar Hahn
2012-01-20 10:50 ` Keir Fraser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CB3F20EC.293DD%keir.xen@gmail.com \
--to=keir.xen@gmail.com \
--cc=Ian.Campbell@citrix.com \
--cc=dietmar.hahn@ts.fujitsu.com \
--cc=haitao.shan@intel.com \
--cc=wei.wang2@amd.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.