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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel