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: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Mon, 3 Sep 2007 12:25:21 +0800
Delivery-date: Sun, 02 Sep 2007 21:25:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2FF54E0.D27C%Keir.Fraser@xxxxxxxxxxxx>
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>
References: <D470B4E54465E3469E2ABBC5AFAC390F013B21BE@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C2FF54E0.D27C%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acfqh8RwaTy8r4iaT0y7Njlwu+54dgAROIeQAAbzeNkAABsToAABWQIjAB9V6qAAErBLqwAKHGtwAAEaJJoAEo/UwAAWs08+AATSlUAAAaaT2AAAE0xAAAKCnfMAAB1ScAACgm12AEqFSeA=
Thread-topic: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2007年9月2日 0:42
>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,
>unpinned dom0 kernel is likely to get very confused about CPU APIC IDs
>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
>means that having C-states controlled from dom0 kernel (no userland
>at all) has similar limitation.

Yes, dom0 may not summarize same information as on native if it lacks 
of correct knowledge to the environment, unless we change dom0 logic.

>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
>\_GPE.xxx object would be idempotent and hence safe to do from dom0
>userspace? Then we could always evaluate it before _CST.

I don't think so. ACPI content is BIOS/OEM specific, and we can't make 
assumption here unless we analyze them and list only supported 
BIOS/platforms (definitely not what we want)

>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
>:-) Otherwise we tie ourselves in knots for cases that may not exist. So
>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
>and be incrementally improved.

Agree on this suggestion. Actually I really can't come up reason why 
available C-states may change especially on server platform. :-)


Xen-devel mailing list