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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.01.16 at 10:27, <van.freenix@xxxxxxxxx> 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@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?

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.

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.

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

Jan


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