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

[Peng Fan <van.freenix@xxxxxxxxx>]

Hi Jan,

On Fri, Jan 22, 2016 at 12:36:31AM -0700, Jan Beulich wrote:
>>>> On 22.01.16 at 02:56, <van.freenix@xxxxxxxxx> wrote:
>> On Thu, Jan 21, 2016 at 05:52:12AM -0700, Jan Beulich wrote:
>>>At the very least it would need to be avoided by denying the request.
>>>Upon shared use, either all parties agree, or only one may use the
>>>clock. And passing through a (platform) device would therefore imply
>>>validating that the needed clock(s) are available to the target domain.
>>>Doing this in a consistent way with all control in one component's
>>>hands seems doable only if hypervisor and/or tool stack are the
>>>controlling (and arbitrating) entity. In the end this is one of the
>>>reasons why to me a simple PV I/O interface doesn't seem suitable
>>>here.
>> 
>> How about let userspace libxl pvclk code to denying the request?
>
>Userspace would be fine, but

Then you are ok with the pvclk way to handle clock for platform device 
passthrough?

>- How would this fit in your frontend/backend model, where
>  userspace shouldn't be involved at all?

rethought about this. clk is binded to device. we can not passthrough
one device to two guest, so this means we can not let two different
guest access one clk input. Since this is mainly for embedded products,
just as Ian said "experts option", the developer should be aware of
the clk sharing between two device.

If we truly need to let userspace deny the request. If one clk
already assigned to Dom1, then the toolstack need to fail
the creation of Dom2, if Dom2 want to use the same clock.

In xl configuraiton file for Dom1, introduce such an entry,
vclks=["gpu_root_clk,uart2_root_clk,usdhc2_root_clk"]
and toolstack will create the xenstore nodes.
/local/domain/0/backend/vclk/1/0/nrclks-->3
/local/domain/0/backend/vclk/1/0/clk-0/name-->gpu_root_clk
/local/domain/0/backend/vclk/1/0/clk-1/name-->uart2_root_clk
/local/domain/0/backend/vclk/1/0/clk-2/name-->usdhc2_root_clk

/local/domain/1/device/vclk/0/clk-ring-ref
/local/domain/1/device/vclk/0/event-channel

The DomU dts also contains the clk names. Maybe the dts for clk node can 
be created by the toolstack.

If Dom2 also want to use gpu_root_clk, it should be blocked by toolstack.


Thanks,
Peng.
>- Libxl may be a little too high up the stack, libxc would seem a
>  more appropriate place to me (but that's subject to tools
>  maintainers disagreeing with me).
>
>Jan
>

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