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

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

Hi Jan,

On Fri, Jan 22, 2016 at 03:25:40AM -0700, Jan Beulich wrote:
>>>> On 22.01.16 at 10:27, <van.freenix@gmail.com> wrote:
>> Hi Jan,
>> 
>> On Fri, Jan 22, 2016 at 12:36:31AM -0700, Jan Beulich wrote:
>>>>>> On 22.01.16 at 02:56, <van.freenix@gmail.com> 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?
>
>No, not really. While I accept that doing clock management in the
>hypervisor is undesirable, we're still not at the point where such
>a frontend/backend pair would look like the only possible route
>out of a dilemma, and I continue to think that this proposed model
>should indeed only be the last resort.

Thanks for following the thread and giving comments.
Alougth this frustrate me, we still need to find a better option for this.

>
>In particular, with the user space exposure of clock control
>discussed in another sub-thread, the next best option would
>seem to be to handle this via emulation in a device model. Yes,
>ARM guests currently have no qemu attached to them, but I
>guess sooner or later this will need to change anyway.

I have not look into qemu for xen.
If using qemu, then we still need to expose the clk interface to userspace?

>
>>>- 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.
>
>I.e. you're now proposing actual assignment of clocks to guests?
>That's at least one step in the (from my pov) right direction...

Based on the pvclk, I am coding the userspace tool part. Alought we have
not find a good solution for this, I first need it work on my platform.

Later I'll also try the fixed clock way.

Thanks,
Peng.
>
>Jan
>