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?

Yeah. the drivers should be ready to cope with this.

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

Let user to configure such as pinctrl and clk for the platform device in Dom0.
But the clk is set at a fixed rate and let the device in DomU use it.
To embedded products, power usage is sensitive. If I passed through GPU controller
to DomU, and fix the clock rate at 400M in Dom0, it will consume more power than let DomU
change the rate. Also platform device passthrough is not hotplugable now, this means
that the gpu controller will always be alive and clock is always enabled.
I am not sure whether this is acceptable or not.

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

vfio is new to me. Just google it. iommu is not a must for platform device passthrough.
If the platform device supports DMA, then smmu is a must.

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

Thanks for clarifying.

Thanks,
Peng.

>
>Ian.
>>