Re: [Xen-devel] [PATCH 2 of 2] linux-xencommons: Load processor-passthru

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.02.12 at 02:46, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> On Fri, Feb 24, 2012 at 10:44:54AM +0000, Jan Beulich wrote:
>> >>> On 24.02.12 at 07:43, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 
>> >>> wrote:
>> > # HG changeset patch
>> > # User Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
>> > # Date 1330065828 18000
>> > # Node ID aa3a294327ed075bafbe3c070b39e3dbacbc49cd
>> > # Parent  a34b652afb0ca484b7416008c95fd36ffbbea334
>> > linux-xencommons: Load processor-passthru
>> > 
>> > The processor-passthru module is used in the upstream kernels
>> > to upload power management information to the hypervisor. We
>> > need to load it to work first.
>> 
>> Hmm, I don't really like this (and prior) pvops-specific additions here,
>> even if stderr gets directed into nowhere. I don't think this (and any
>> other) script intended to target Linux in general should target just
>> a specific implementation.
>> 
>> Furthermore, given the purpose of the driver, I'm thinking that this
>> is too late in the boot process anyway, and the driver should rather
>> be loaded at the point where other CPUFreq drivers would normally
>> be by a particular distro (which would still be later than when the
>> respective code gets run on traditional Xenified Linux).
> 
> My thinking is to keep the amount of changes to be within the Xen-ecosystem.
> 
> Doing the changes in the old-fashioned way in drivers/acpi has not been
> very productive - so I've been looking at just some form of uploading
> the PM information to the hypervisor. And I've been piggybacking on
> top of the cpufreq scaling drivers collecting the information. So with that 
> in mind, the next idea I had was to provide a cpufreq governor, called 'xen'
> which would inhibit the cpufreq scaling drivers from changing anything in 
> dom0
> (so that the hypervisor can do it instead). Also it would be responsible
> for uploading the PM information to the hypervisor. See attached.
> 
> The fix to the tool-stack would be something along:
> # HG changeset patch
> # Parent 917f845f3e838dcc1efccb132abe2d1f254cb7b8
> 
> diff -r 917f845f3e83 tools/hotplug/Linux/init.d/xencommons
> --- a/tools/hotplug/Linux/init.d/xencommons   Thu Feb 23 13:29:00 2012 -0500
> +++ b/tools/hotplug/Linux/init.d/xencommons   Fri Feb 24 21:42:20 2012 -0500
> @@ -58,7 +58,7 @@ do_start () {
>       modprobe xen-gntdev 2>/dev/null
>       modprobe evtchn 2>/dev/null
>       modprobe gntdev 2>/dev/null
> -
> +     for file in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do 
> echo xen > $file; done 2>/dev/null

While not an unreasonable idea (yes, I sort of contradict my other mail
from a few minutes ago, given your explanation above), this won't work
with subsequently onlined vCPU-s (and hence, consistent with my other
mail, having the thing be a governor is likely the wrong choice - it ought
to be a driver).

Jan

>       if ! `xenstore-read -s / >/dev/null 2>&1`
>       then
>               test -z "$XENSTORED_ROOTDIR" || 
> XENSTORED_ROOTDIR="/var/lib/xenstored"




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel