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

["Yu, Ke" <ke.yu@xxxxxxxxx>]

>From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
>Sent: Tuesday, July 21, 2009 3:34 AM
>To: Yu, Ke
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel