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

[Peng Fan <van.freenix@xxxxxxxxx>]

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.

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

Thanks,
Peng.

>
>Ian.
>
>[0] Documentation/devicetree/bindings/clock/fixed-clock.txt
>

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