Re: [RFC V2] xen: interface: introduce pvclk interface

[Peng Fan <van.freenix@gmail.com>]

Hi Ian,

On Thu, Jan 21, 2016 at 12:49:24PM +0000, Ian Campbell wrote:
>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).

Sorry to bother you again on this.

For the fixed clock method, I add such a xl cfg entry: devclk=["uart_root_clk,24000000", "gpu_root_clk,200000000"].
After add code for writeing sysfs clk node in libxl, the clk can be set rate/prepared/enabled.
But I do not know the resource release path, when need to shutdown/destroy a domain. For example:
when domain creation, the clk is prepared, when domain destroied, I want the clk unprepared. But I
do not find out the code path to releasing resource.

Also, since need to add fixed-clock nodes in DomU dts, do you agree to let libxl or xc to create the nodes
in dts, but not mannually add them in passthrough node?

Thanks,
Peng.

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