From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com>,
Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH RFC 2/2] xen/x86: Introduce XEN_SYSCTL_cpuid hypercall
Date: Thu, 27 Feb 2014 15:57:22 +0000 [thread overview]
Message-ID: <530F6062.2040302@citrix.com> (raw)
In-Reply-To: <530F3CF8020000780011FD40@nat28.tlf.novell.com>
On 27/02/14 12:26, Jan Beulich wrote:
>>>> On 27.02.14 at 13:11, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Apart from forcibly messing with a balanced numa setup, what about cpu
>> pools, or toolstack disaggregation where pinning is restricted?
> There no messing with a balanced setup here - everything should
> of course be transient, i.e. get restored to previous values right
> after.
But anything else happening on that vcpu at the same time is transiently
out of balance.
> And I can't see a reason not to permit the hardware domain
> to temporarily escape its enclave, as it can do worse to the overall
> system anyway.
True
>
> The new hypercall is simple enough (yet very x86-centric) that I'm
> not really against it; what I'm against is adding functionality to the
> hypervisor that is already available by other means.
>
> Jan
>
As I said before, the cache information is faked up by the cpuid policy,
so might be subject to policy depending on faulting or non-dom0 hardware
domian, or PVH dom0 in the near future.
I think there is a legitimate case for "I really truely need the real
hardware values, without anything in the policy getting in the way".
'cpuid' is indeed very x86 specific, but it is not information readily
available by other means.
~Andrew
next prev parent reply other threads:[~2014-02-27 15:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-27 11:11 [PATCH RFC 0/2] Support for hwloc Andrew Cooper
2014-02-27 11:11 ` [PATCH RFC 1/2] tools/libxc: Improved xc_{topology, numa}info functions Andrew Cooper
2014-03-12 8:34 ` Dario Faggioli
2014-03-12 10:41 ` Andrew Cooper
2014-03-12 11:00 ` Dario Faggioli
2014-03-14 14:41 ` Ian Campbell
2014-02-27 11:11 ` [PATCH RFC 2/2] SYSCTL subop to execute cpuid on a specified pcpu Andrew Cooper
2014-02-27 11:11 ` [PATCH RFC 2/2] xen/x86: Introduce XEN_SYSCTL_cpuid hypercall Andrew Cooper
2014-02-27 11:58 ` Jan Beulich
2014-02-27 12:11 ` Andrew Cooper
2014-02-27 12:26 ` Jan Beulich
2014-02-27 15:57 ` Andrew Cooper [this message]
2014-03-14 14:45 ` Ian Campbell
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=530F6062.2040302@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=keir@xen.org \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).