WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] RE: [PATCH][pvops_dom0][0/4] parse ACPI Cx/Px info for Xen
From: "Yu, Ke" <ke.yu@xxxxxxxxx>
Date: Tue, 21 Jul 2009 16:12:25 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 21 Jul 2009 01:13:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A64C6C3.90904@xxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D05DB80B95B23498C72C700BD6C2E0B2FBF1987@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4A64C6C3.90904@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcoJcRuuOUFYblRYR8C1B+XHqZohMAAXsGnA
Thread-topic: [PATCH][pvops_dom0][0/4] parse ACPI Cx/Px info for Xen
>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

<Prev in Thread] Current Thread [Next in Thread>