From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peng Fan Subject: Re: [RFC V2] xen: interface: introduce pvclk interface Date: Sat, 23 Jan 2016 23:26:11 +0800 Message-ID: <20160123152608.GA13634@linux-7smt.suse> References: <20160120143719.GD10911@linux-7smt.suse> <569FAD5A02000078000C931D@prv-mh.provo.novell.com> <20160121012943.GA11729@linux-7smt.suse> <56A09C6D02000078000C970F@prv-mh.provo.novell.com> <20160121085858.GA15664@linux-7smt.suse> <1453371572.26343.210.camel@citrix.com> <20160121115510.GA29399@linux-7smt.suse> <1453379164.4320.30.camel@citrix.com> <20160121123534.GC29399@linux-7smt.suse> <1453380564.4320.35.camel@citrix.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 1aN09L-0003jX-Fe for xen-devel@lists.xenproject.org; Sat, 23 Jan 2016 15:30:51 +0000 Received: by mail-pa0-f50.google.com with SMTP id cy9so57240302pac.0 for ; Sat, 23 Jan 2016 07:30:49 -0800 (PST) Content-Disposition: inline In-Reply-To: <1453380564.4320.35.camel@citrix.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: Ian Campbell Cc: Stefano Stabellini , George Dunlap , Julien Grall , David Vrabel , Jan Beulich , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org Hi Ian, On Thu, Jan 21, 2016 at 12:49:24PM +0000, Ian Campbell wrote: >On Thu, 2016-01-21 at 20:35 +0800, Peng Fan wrote: >> On Thu, Jan 21, 2016 at 12:26:04PM +0000, Ian Campbell wrote: >> > Would adding a dummy fixed-clock[0] (or several of them) to the guest >> > passthrough DT satisfy the driver's requirements? They would be hardcoded >> > to whatever rate dom0 and/or the tools has decided upon (and had set in the >> > real h/w). >> >> If using this way, we have the assumption that DomU device driver would not >> change the rate of the clock driving the device. I am not sure whether this is >> ok for so many platform devices based ARM core. > >Don't (non-buggy) drivers already need to cope with the possibility that >the clk core may not be able to satisfy their request for a particular rate >due to constraints from other ip blocks? > >I would also expect the user to want to configure things in dom0 such that >the specific drivers used in domU are satisfied with what they get (which >is a bit fiddly perhaps, but platform device passthrough already is >somewhat that way). > >> In /sys/kernel/debug/clk/...., there are clk tree info, but >> clk api are not exposed to userspace as far as I know, so >> if using sysfs interface to set a known fixed rate or enable/disable the clock, >> we need to expose the clk info to userspace. > >That seems possible to arrange given a use case for it though, a SMOP (and >convincing the clk maintainer of the need). Sorry to bother you again on this. For the fixed clock method, I add such a xl cfg entry: devclk=["uart_root_clk,24000000", "gpu_root_clk,200000000"]. After add code for writeing sysfs clk node in libxl, the clk can be set rate/prepared/enabled. But I do not know the resource release path, when need to shutdown/destroy a domain. For example: when domain creation, the clk is prepared, when domain destroied, I want the clk unprepared. But I do not find out the code path to releasing resource. Also, since need to add fixed-clock nodes in DomU dts, do you agree to let libxl or xc to create the nodes in dts, but not mannually add them in passthrough node? Thanks, Peng. > >Worst case is a xen-clkback driver or perhaps even vfio will want to do >something like this, we can't normally use vfio on Xen, but in this case >perhaps we could. > > >> Jan said using hypercall in the other mail, do you have any ideas about >> this? > >This would need a whole clock infrastructure in Xen, wouldn't it? I >described why that is not currently available in an earlier mail, and also >my opinion that doing the whole thing in Xen would involve pulling in far >too much SoC specific code for each specific platform. > >Ian. >>