Xen devel - Jul 2009 - [PATCH][pvops_dom0][0/4] parse ACPI Cx/Px info for Xen

Xen hypervisor depends on dom0 to parse the physical ACPI Cx/Px information and
pass the info to xen. The following series of patches implements this
functionality:

01/04 domain0-acpi-parser-related-hypercall.patch:  	add acpi parser related
platform hypercall
02/04 external-control-framework.patch:  			Introduce the external control
operation interface for domain0 ACPI parser
03/04 external-control-xen.patch:					Xen implementation of the external control
operation interface
04/04 xen-vcpu-pcpu-mapping.patch: 				use physical acpi_id in acpi processor
parsing logic

Note that the 04 patch xen-vcpu-pcpu-mapping.patch is a bit hacky. Its purpose
is fixing the gap between dom0 vcpu and physical acpi info. but due to that this
is a the architecture issue, no clean way is found with current architecture.
There is thread talking about moving the ACPI parser from dom0 to hypervisor.
this issue will gone under such architecture. But by far, we have to use this
kind of hacky patch.

Also this series of patches are rebased version of the previous post. Most of
the comments Jeremy provided last time is applied, with only one exception: use
xen specific cpufreq driver for the Px info. I tried this approach, and finally
find this approach need many hacks in cpufreq path to fix the gap of vcpu and
physical cpu. so I still keep the Px logic in external control logic instead of
cpufreq driver.

Best Regards
Ke



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

On 07/18/09 23:45, Yu, Ke wrote:
> Note that the 04 patch xen-vcpu-pcpu-mapping.patch is a bit hacky. Its
purpose is fixing the gap between dom0 vcpu and physical acpi info. but due to
that this is a the architecture issue, no clean way is found with current
architecture. There is thread talking about moving the ACPI parser from dom0 to
hypervisor. this issue will gone under such architecture. But by far, we have to
use this kind of hacky patch.
>
> Also this series of patches are rebased version of the previous post. Most
of the comments Jeremy provided last time is applied, with only one exception:
use xen specific cpufreq driver for the Px info. I tried this approach, and
finally find this approach need many hacks in cpufreq path to fix the gap of
vcpu and physical cpu. so I still keep the Px logic in external control logic
instead of cpufreq driver.
>   
Thats unfortunate.  Could you go into a bit more detail about the
problem with the pcpu/vcpu gap?  I wonder if this could be dealt with in
some other way?  For example, since it never(?) makes sense for cpufreq
to operate in terms of vcpus, could the interface be defined to always
operate in terms of pcpus, this erasing the gap?

(I can see lots of problems with this suggestion, but I''m just throwing
it up as a discussion point.)

    J

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

>From: Jeremy Fitzhardinge [mailto:jeremy@goop.org]
>Sent: Tuesday, July 21, 2009 3:34 AM
>To: Yu, Ke
>Cc: xen-devel@lists.xensource.com; Tian, Kevin
>Subject: Re: [PATCH][pvops_dom0][0/4] parse ACPI Cx/Px info for Xen
>
>On 07/18/09 23:45, Yu, Ke wrote:
>> Note that the 04 patch xen-vcpu-pcpu-mapping.patch is a bit hacky. Its
>purpose is fixing the gap between dom0 vcpu and physical acpi info. but due
>to that this is a the architecture issue, no clean way is found with current
>architecture. There is thread talking about moving the ACPI parser from
>dom0 to hypervisor. this issue will gone under such architecture. But by
far,
>we have to use this kind of hacky patch.
>>
>> Also this series of patches are rebased version of the previous post.
Most of
>the comments Jeremy provided last time is applied, with only one exception:
>use xen specific cpufreq driver for the Px info. I tried this approach, and
finally
>find this approach need many hacks in cpufreq path to fix the gap of vcpu
and
>physical cpu. so I still keep the Px logic in external control logic instead
of
>cpufreq driver.
>>
>
>Thats unfortunate.  Could you go into a bit more detail about the
>problem with the pcpu/vcpu gap?  I wonder if this could be dealt with in
>some other way?  For example, since it never(?) makes sense for cpufreq
>to operate in terms of vcpus, could the interface be defined to always
>operate in terms of pcpus, this erasing the gap?
>
>(I can see lots of problems with this suggestion, but I''m just
throwing
>it up as a discussion point.)
>
>    J
it is related to the question in patch 4/4, please see my reply in that email.

Best Regards
Ke

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