[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: [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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |