From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "Yu, Ke" <ke.yu@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH][pvops_dom0][0/4] parse ACPI Cx/Px info for Xen
Date: Mon, 20 Jul 2009 12:34:27 -0700 [thread overview]
Message-ID: <4A64C6C3.90904@goop.org> (raw)
In-Reply-To: <4D05DB80B95B23498C72C700BD6C2E0B2FBF1987@pdsmsx502.ccr.corp.intel.com>
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
next prev parent reply other threads:[~2009-07-20 19:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-19 6:45 [PATCH][pvops_dom0][0/4] parse ACPI Cx/Px info for Xen Yu, Ke
2009-07-20 19:34 ` Jeremy Fitzhardinge [this message]
2009-07-21 8:12 ` Yu, Ke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A64C6C3.90904@goop.org \
--to=jeremy@goop.org \
--cc=ke.yu@intel.com \
--cc=kevin.tian@intel.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.