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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 10 Sep 2014, Andrii Tseglytskyi wrote:
> Hi,
> 
> On Wed, Sep 10, 2014 at 12:42 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
> wrote:
> >
> > 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.
> 
> I would try to avoid i2c transactions in Xen. I2C driver is quite
> complicated in Linux kernel. It consists of several parts - common
> core + platform specific. I'm pretty sure Xen should not handle this.
> I think that establishing of event channel for frequency changing is a
> good idea. It would be good to try to implement this. In process of
> implementation we will see what is need to be resolved.

OK, that's reasonable.


> The only question here is how to pass physical cpu to dom0.

We can use a device tree based interface to pass the information to
dom0, but requiring a number of dom0 vcpus equal to the number of
physical cpus and in addition to that having to pin the vcpus each to a
different pcpu is quite a stringent limitation. However I don't know the
frequency changing interfaces in Linux well enough to know how hard
would be to lift it.


> Regarding x86.
> I'm not sure but maybe ACPI interface encapsulate voltage changing as well?

I think so (but I am not an expert on that).



> Regards,
> Andrii
> 
> 
> -- 
> 
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com
> 

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