From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Len Brown <lenb@kernel.org>
Cc: venki@google.com, ak@linux.intel.com, suresh.b.siddha@intel.com,
sfr@canb.auug.org.au, peterz@infradead.org,
benh@kernel.crashing.org,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
arjan@linux.intel.com, Trinabh Gupta <trinabh@linux.vnet.ibm.com>
Subject: Re: Re: [RFC PATCH V4 4/5] cpuidle: driver for xen
Date: Fri, 25 Mar 2011 14:43:14 +0000 [thread overview]
Message-ID: <4D8CAA02.2020403@goop.org> (raw)
In-Reply-To: <alpine.LFD.2.02.1103250315180.32565@x980>
On 03/25/2011 07:19 AM, Len Brown wrote:
> The Xen Dom0 kernel will trap into the hypervisor
> whenever it does a HLT or an MWAIT, yes?
Yes, on hlt.
> What is the benefit of having Dom0 decided between
> C-states that it can't actually enter?
There might be a slight benefit to allow a domain to tell Xen what its
overall utilisation is (ie, "I'd like this VCPU to run, but it isn't
very important so you can take that into account when choosing
scheduling priority and/or PCPU performance"). But there's nothing like
that at present.
> What is the mechanism by which those C-states are
> made visible to Dom0, and how are those states
> related to the states that are supported on
> the bare iron?
Because dom0 is the official ACPI owner (ie, it has the AML
interpreter), we need dom0 to handle complex interactions with ACPI (the
hypervisor can do simple table parsing). At present the mechanism for
power states is that dom0 gets them out of ACPI, and then passes them to
Xen which actually uses them. But no guest kernel has any runtime use
of power states.
J
next prev parent reply other threads:[~2011-03-25 14:43 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20110322123208.28725.30945.stgit@tringupt.in.ibm.com>
[not found] ` <20110322123324.28725.3131.stgit@tringupt.in.ibm.com>
2011-03-22 14:50 ` [RFC PATCH V4 4/5] cpuidle: driver for xen Konrad Rzeszutek Wilk
2011-03-23 9:57 ` Trinabh Gupta
2011-03-24 7:18 ` Len Brown
2011-03-24 12:05 ` Konrad Rzeszutek Wilk
2011-03-25 7:19 ` Len Brown
2011-03-25 14:43 ` Jeremy Fitzhardinge [this message]
2011-03-25 14:38 ` [Xen-devel] " Jeremy Fitzhardinge
2011-03-31 2:02 ` Len Brown
2011-03-31 21:26 ` Len Brown
2011-03-31 22:36 ` [Xen-devel] " Jeremy Fitzhardinge
2011-04-01 3:03 ` Len Brown
[not found] ` <20110322123233.28725.92874.stgit@tringupt.in.ibm.com>
[not found] ` <alpine.LFD.2.02.1103222254420.10549@x980>
2011-03-23 9:22 ` [RFC PATCH V4 2/5] cpuidle: list based cpuidle driver registration and selection Trinabh Gupta
2011-03-23 20:51 ` Len Brown
2011-03-24 4:41 ` Len Brown
2011-03-24 14:13 ` Trinabh Gupta
2011-03-24 16:52 ` Vaidyanathan Srinivasan
2011-03-25 7:13 ` Len Brown
2011-03-25 7:05 ` Len Brown
2011-03-25 15:35 ` [Xen-devel] " Konrad Rzeszutek Wilk
2011-03-31 2:25 ` Len Brown
[not found] ` <20110322123244.28725.32435.stgit@tringupt.in.ibm.com>
[not found] ` <alpine.LFD.2.02.1103222304300.10549@x980>
2011-03-23 9:31 ` [RFC PATCH V4 3/5] cpuidle: default idle driver for x86 Trinabh Gupta
2011-03-24 16:32 ` Vaidyanathan Srinivasan
[not found] ` <20110322123223.28725.21929.stgit@tringupt.in.ibm.com>
[not found] ` <20110323120044.bb8c0ae1.sfr@canb.auug.org.au>
2011-03-23 10:10 ` [RFC PATCH V4 1/5] cpuidle: Remove pm_idle pointer " Trinabh Gupta
[not found] ` <20110322123336.28725.29810.stgit@tringupt.in.ibm.com>
[not found] ` <20110323121458.ec7cdaf9.sfr@canb.auug.org.au>
2011-03-23 10:25 ` [RFC PATCH V4 5/5] cpuidle: cpuidle driver for apm Trinabh Gupta
2011-03-23 20:32 ` Len Brown
2011-03-24 14:28 ` Trinabh Gupta
2011-03-24 16:21 ` Vaidyanathan Srinivasan
2011-03-25 7:24 ` Len Brown
2011-03-25 18:01 ` Vaidyanathan Srinivasan
2011-03-31 2:17 ` cpuidle asymmetry (was Re: [RFC PATCH V4 5/5] cpuidle: cpuidle driver for apm) Len Brown
2011-03-31 13:18 ` Peter Zijlstra
2011-04-01 4:09 ` Len Brown
2011-04-01 8:15 ` Dipankar Sarma
2011-04-01 14:38 ` Arjan van de Ven
2011-04-03 16:18 ` Dipankar Sarma
2011-04-01 14:02 ` Peter Zijlstra
2011-04-04 14:32 ` Dipankar Sarma
2011-04-05 15:01 ` Peter Zijlstra
2011-04-05 15:48 ` Dipankar Sarma
2011-04-01 7:02 ` Trinabh Gupta
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=4D8CAA02.2020403@goop.org \
--to=jeremy@goop.org \
--cc=ak@linux.intel.com \
--cc=arjan@linux.intel.com \
--cc=benh@kernel.crashing.org \
--cc=konrad.wilk@oracle.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=sfr@canb.auug.org.au \
--cc=suresh.b.siddha@intel.com \
--cc=trinabh@linux.vnet.ibm.com \
--cc=venki@google.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 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).