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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>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,
>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.

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
>appropriate
>\_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
>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.
>

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

Thanks,
Kevin

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