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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2016-01-21 at 20:35 +0800, Peng Fan wrote:
> On Thu, Jan 21, 2016 at 12:26:04PM +0000, Ian Campbell wrote:
> > 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.

Don't (non-buggy) drivers already need to cope with the possibility that
the clk core may not be able to satisfy their request for a particular rate
due to constraints from other ip blocks?

I would also expect the user to want to configure things in dom0 such that
the specific drivers used in domU are satisfied with what they get (which
is a bit fiddly perhaps, but platform device passthrough already is
somewhat that way).

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

That seems possible to arrange given a use case for it though, a SMOP (and
convincing the clk maintainer of the need).

Worst case is a xen-clkback driver or perhaps even vfio will want to do
something like this, we can't normally use vfio on Xen, but in this case
perhaps we could.


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

This would need a whole clock infrastructure in Xen, wouldn't it? I
described why that is not currently available in an earlier mail, and also
my opinion that doing the whole thing in Xen would involve pulling in far
too much SoC specific code for each specific platform.

Ian.
> 

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