[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface
Hi Jan, On Fri, Jan 22, 2016 at 03:25:40AM -0700, Jan Beulich wrote: >>>> 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. 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 > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |