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/
Home Products Support Community News


Re: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sat, 01 Sep 2007 17:41:52 +0100
Delivery-date: Sat, 01 Sep 2007 09:37:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F013B21BE@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acfqh8RwaTy8r4iaT0y7Njlwu+54dgAROIeQAAbzeNkAABsToAABWQIjAB9V6qAAErBLqwAKHGtwAAEaJJoAEo/UwAAWs08+AATSlUAAAaaT2AAAE0xAAAKCnfMAAB1ScAACgm12
Thread-topic: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
User-agent: Microsoft-Entourage/
On 1/9/07 16:45, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> Maybe I'm too nervous and actual implementation may be very simple.
> But ACPI does allow above condition.

Yes, I hadn't thought of the possibility of local variables being modified
in the \_GPE.xxx method. Yuk.

There are other problems relying on the kernel to notify us. For a start, an
unpinned dom0 kernel is likely to get very confused about CPU APIC IDs and
hence map processor objects incorrectly onto physical cpus, and quite
possibly fail to register some processor objects entirely. That whole area
is a mess without vcpu pinning (not something we want to rely on). This also
means that having C-states controlled from dom0 kernel (no userland program
at all) has similar limitation.

Can we rely on from-scratch evaluation of DSDT and SSDTs to get us
up-to-date C-state info? Perhaps we could trigger that via infrequent
polling or some suitable low-level event (e.g., SCI count going up in
/proc/interrupts)? Or could we be confident that evaluating the appropriate
\_GPE.xxx object would be idempotent and hence safe to do from dom0
userspace? Then we could always evaluate it before _CST.

It's also possible that we should implement something simple, and then
complicate it just as much as we need to based on testing on real systems.
:-) Otherwise we tie ourselves in knots for cases that may not exist. So I'd
be happy to start with one-shot static C-state determination from dom0
userspace. That can always be disabled if it causes trouble on some systems,
and be incrementally improved.

 -- Keir

Xen-devel mailing list