WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [RFC PATCH V4 4/5] cpuidle: driver for xen

To: Len Brown <lenb@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [RFC PATCH V4 4/5] cpuidle: driver for xen
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Fri, 25 Mar 2011 14:43:14 +0000
Cc: venki@xxxxxxxxxx, ak@xxxxxxxxxxxxxxx, suresh.b.siddha@xxxxxxxxx, sfr@xxxxxxxxxxxxxxxx, peterz@xxxxxxxxxxxxx, benh@xxxxxxxxxxxxxxxxxxx, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, arjan@xxxxxxxxxxxxxxx, Trinabh Gupta <trinabh@xxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 25 Mar 2011 07:43:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.LFD.2.02.1103250315180.32565@x980>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20110322123208.28725.30945.stgit@xxxxxxxxxxxxxxxxxxx> <20110322123324.28725.3131.stgit@xxxxxxxxxxxxxxxxxxx> <20110322145054.GB26952@xxxxxxxxxxxx> <4D89C40B.4020809@xxxxxxxxxxxxxxxxxx> <alpine.LFD.2.02.1103231659210.12911@x980> <20110324120522.GB29294@xxxxxxxxxxxx> <alpine.LFD.2.02.1103250315180.32565@x980>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.9
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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel