Re: [Xen-devel] cpufreq implementation for OMAP under xen hypervisor.

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-09-09 at 22:41 +0100, Stefano Stabellini wrote:
> On Tue, 9 Sep 2014, Ian Campbell wrote:
> > On Thu, 2014-09-04 at 22:56 +0100, Stefano Stabellini wrote:
> > > I am trying to think of an alternative, such as passing the real cpu
> > > nodes to dom0 but then adding status = "disabled", but I am not sure
> > > whether Linux checks the status for cpu nodes.
> > 
> > status = "disabled" is defined to have a specific (i.e. non-default)
> > meaning for cpu nodes, Julien mentioned this when I tried to add a
> > similar patch to Xen to ignore them. I think it basically means "present
> > but not running, you should start them!".
> > 
> > >  In addition this scheme
> > > wouldn't support the case where dom0 has more vcpus than pcpus on the
> > > system. Granted it is not very common and might even be detrimental for
> > > performances, but we should be able to support it.
> > 
> > It's a bit of an edge case, for sure. I guess it wouldn't be totally
> > unreasonable to say that if you use this sort of configuration you may
> > not get cpufreq support.
> > 
> > > Ian, what do you think about this?
> > 
> > All the options suck in one way or another AFAICT. I think we are going
> > to be looking for the least bad solution not necessarily a good one.
> > 
> > Fundamentally are we trying to avoid having to have a i2c subsystem etc
> > in the hypervisor to be be able to change the voltages before/after
> > changing the frequency?
> >
> > We can't just say "that's part of the cpufreq driver" since different
> > boards using the same SoC might use different voltage regulators, over
> > i2c or some other bus etc, so we end up with a matrix.
> > 
> > It's arguable that we should be letting dom0 poke at that regulator
> > functionality anyway, at least not all of it. Taking that ability away
> > would necessarily imply more platform specific functionality in the
> > hypervisor.
> 
> Right.
> I am afraid that in order to avoid more code in Xen, we end up with an
> unmaintainable interface and unupstreamable hacks in dom0.

That's what I'm worried about to. Hence I'm wondering if we should just
do this in the hypervisor.

Although there are a myriad of them the parts used to do voltage control
tend to be fairly simple.

One concern I have is that i2c busses also tend to have other things on
them which dom0 might legitimately access (e.g. rtc), I'm not sure what
to suggest here.

> > How does this stuff work on x86?
> 
> As far as I can tell, after an initial version based on Dom0 doing the
> work, the functionality has been moved into the hypervisor.
> Of course doing that is easier on x86 where differences across
> platforms are more limited.

This chimes with my limited understanding. I think we still need a dom0
component to feed stuff down from ACPI to let Xen do its work, is that
right? Or do we go under the hood and ignore ACPI PM somehow?

Ian.


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