RE: [Xen-devel] [PATCH 2] Add user PM control interface

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Jan Beulich
>Sent: Wednesday, December 10, 2008 6:41 PM
>
>>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 10.12.08 11:32 >>>
>>Really in this case it depends: is support for Linux pm tools 
>going to be
>>practically useful, especially in the general cases such as 
>#dom0-cpus !=
>>#physical-cpus? It does seem a bit dubious to me.
>
>I'm not certain either, which is why I asked whether this was 
>sync-ed with
>the maintainers of these tools.
>

I don't think supporting linux pm tools an easy work, or even
a sane stuff:

First, dom0 doesn't have global view to whole system. For example,
PowerTOP relies on /proc/interrupts to count for break event
summary. Then you need tweak that interface to include irqs
owned by Xen and other domains, and update its status when
it's opened for read. More important is, I don't think every device
owned by xen/domU can find a placeholder within dom0's 
namespace, considering current per-domain pirq, or in future 
maybe per-cpu local vector allocation. Even that's viable, finally
it'd be still preferred to have some virtualization aware concept
e.g. to report a more informative result like which domains 
contribute how many break events instead of a raw information.

Then, It's a mess to mix cpu nodes between those available
to dom0 and other nodes which are only placeholder to carry
physical cpu attribute. Especially for those combining both
purposes, for example, some attributes under cpu0 node is 
for dom0's vcpu0 and others for physical cpu0. You have to
disable existing linux stuff in case contending for same attribute, and
those lines may be not a single module and then you need
add condition check into those common files. Also it's possible
for user request failed to reach xen specific driver, due to some
higher level check on vcpu existence. 

IOW, I'm inclined to think in future virtualization specific pm tool
would be more useful, which acquire hypervisor pm stats directly
and then can show a more informative picture to user. That said,
I'd like to see current domctl/sysctl approach as the base for
subsequent pm area development. Xenpm is the only user on
those interface by far, which can be a good example for more 
advanced pm tools since we already provide equivalent control
knobs as linux side. People can try to support linux pm tools by
tweaking dom0 kernel, but current approach is the base anyway.

Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel