From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peng Fan Subject: Re: [RFC V2] xen: interface: introduce pvclk interface Date: Fri, 22 Jan 2016 20:12:39 +0800 Message-ID: <20160122121237.GA8192@linux-7smt.suse> References: <20160121012943.GA11729@linux-7smt.suse> <56A09C6D02000078000C970F@prv-mh.provo.novell.com> <20160121085858.GA15664@linux-7smt.suse> <56A0BF4202000078000C980B@prv-mh.provo.novell.com> <20160121120615.GB29399@linux-7smt.suse> <56A0E28C02000078000C995C@prv-mh.provo.novell.com> <20160122015622.GD29399@linux-7smt.suse> <56A1EA0F02000078000C9DE2@prv-mh.provo.novell.com> <20160122092510.GA19346@linux-7smt.suse> <56A211B402000078000C9F68@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aMac1-0002Er-Ld for xen-devel@lists.xenproject.org; Fri, 22 Jan 2016 12:14:45 +0000 Received: by mail-pa0-f45.google.com with SMTP id yy13so40900692pab.3 for ; Fri, 22 Jan 2016 04:14:43 -0800 (PST) Content-Disposition: inline In-Reply-To: <56A211B402000078000C9F68@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Ian Campbell , Stefano Stabellini , George Dunlap , Julien Grall , David Vrabel , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org Hi Jan, On Fri, Jan 22, 2016 at 03:25:40AM -0700, Jan Beulich wrote: >>>> On 22.01.16 at 10:27, wrote: >> Hi Jan, >> >> On Fri, Jan 22, 2016 at 12:36:31AM -0700, Jan Beulich wrote: >>>>>> On 22.01.16 at 02:56, 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 >