Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 21 Jan 2016, Peng Fan wrote:
> Hi Ian,
>
> On Thu, Jan 21, 2016 at 12:26:04PM +0000, Ian Campbell wrote:
> >On Thu, 2016-01-21 at 19:55 +0800, Peng Fan wrote:
> >> Hi Ian,
> >>
> >> On Thu, Jan 21, 2016 at 10:19:32AM +0000, Ian Campbell wrote:
> >> > On Thu, 2016-01-21 at 16:59 +0800, Peng Fan wrote:
> >> > > Â
> >> > > To platform device of ARM, hypervisor is responsible for the mapping
> >> > > between machine address and guest physical address, also responsible
> >> > > for the irq mapping.
> >> > >
> >> > > But to embedded ARM SoC, the hardware clk IP is handled in Dom0.
> >> >
> >> > Arguably Xen ought to be the one to do this, but we have determined
> >> > (rightly, I think) that doing so for the entirely clk tree of an SoC
> >> > would
> >> > involve importing an unmanageable amount of code into Xen[0].
> >> >
> >> > In the meantime we defer this to Dom0.
> >> >
> >> > I wonder though if it would be possible to manage the clocks for a
> >> > passthrough device from the toolstack, i.e. is there a sysfs node where
> >> > one
> >> > can say "keep the clock for this device enabled (at xMhz) even though
> >> > you
> >> > think the device is unused"?
> >>
> >> I am afraid not. The linux device driver without xen can work well,
> >> because
> >> there is clk tree and "clk_get,clk_prepare,clk_set_rate" work well in the
> >> driver.
> >> I do not want to remove the clk apis usage from the device driver for
> >> xen, because the driver
> >> also serves when no xen support. The pvclk interface is mainly to let the
> >> clk api can work as no xen.
> >
> >Would adding a dummy fixed-clock[0] (or several of them) to the guest
> >passthrough DT satisfy the driver's requirements? They would be hardcoded
> >to whatever rate dom0 and/or the tools has decided upon (and had set in the
> >real h/w).
>
> If using this way, we have the assumption that DomU device driver would not
> change the rate of the clock driving the device. I am not sure whether this is
> ok for so many platform devices based ARM core.
>
> In /sys/kernel/debug/clk/...., there are clk tree info, but
> clk api are not exposed to userspace as far as I know, so
> if using sysfs interface to set a known fixed rate or enable/disable the 
> clock,
> we need to expose the clk info to userspace.

Keeping in mind that we might now want to let DomU change the actual
clock frequency anyway, exposing a dummy clock to keep the DomU driver
happy might be a good option.

However whether we set the frequency from the Dom0 kernel or from the
toolstack, how do we find out the right clock rate? From a grep in the
kernel sources, it looks like some drivers still have hardcoded values.

Asking the user to provide the clock rate seems a bit too much to me.


> Jan said using hypercall in the other mail, do you have any ideas about this?

I recall having discussed this in the past and the conclusion was that
moving the clock framework into Xen, so that the hypervisor could
directly control clock frequencies, although it might make sense from an
architectural point of view, would be too complex to be feasible.

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