[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.