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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2016-01-21 at 12:55 +0000, Stefano Stabellini wrote:
> 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

s/now/not/?

> 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.

Remember that for this use case they already need to provide the host DT
path to the device, the list of iomem resources, the list of irqs and a
suitable device tree snippet.

platform device passthrough is very much an "expert" option (intended for
folks building embedded device, not really for normal end users), which
already needs a fair bit of familiarity with the system in question, I
don't think providing some info about the clocks goes too much further than
this.

Seamless & easy passthrough is something we are aiming for for PCI, but not
for the general case of platform passthrough.

Making platform device passthrough as easy as PCI passthrough is much
harder and far reaching than avoiding the need to specify some clock
frequencies (remember we had very long discussions about the design and
couldn't come up with anything especially feasible).

Ian.

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