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

[Andrii Tseglytskyi <andrii.tseglytskyi@xxxxxxxxxxxxxxx>]

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. The only
question here is how to pass physical cpu to dom0.

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

Regards,
Andrii


-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

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