From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peng Fan Subject: Re: [RFC V2] xen: interface: introduce pvclk interface Date: Thu, 21 Jan 2016 20:35:36 +0800 Message-ID: <20160121123534.GC29399@linux-7smt.suse> References: <20160120140550.GB10911@linux-7smt.suse> <569FA4D402000078000C9238@prv-mh.provo.novell.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aMET0-0004Fn-U5 for xen-devel@lists.xenproject.org; Thu, 21 Jan 2016 12:35:59 +0000 Received: by mail-pf0-f174.google.com with SMTP id q63so23741131pfb.1 for ; Thu, 21 Jan 2016 04:35:56 -0800 (PST) Content-Disposition: inline In-Reply-To: <1453379164.4320.30.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:26:04PM +0000, Ian Campbell wrote: >On Thu, 2016-01-21 at 19:55 +0800, Peng Fan wrote: >> Hi Ian, >> = >> On Thu, Jan 21, 2016 at 10:19:32AM +0000, Ian Campbell wrote: >> > On Thu, 2016-01-21 at 16:59 +0800, Peng Fan wrote: >> > > =A0 >> > > To platform device of ARM, hypervisor is responsible for the mapping >> > > between machine address and guest physical address, also responsible >> > > for the irq mapping. >> > > = >> > > But to embedded ARM SoC, the hardware clk IP is handled in Dom0. >> > = >> > Arguably Xen ought to be the one to do this, but we have determined >> > (rightly, I think) that doing so for the entirely clk tree of an SoC >> > would >> > involve importing an unmanageable amount of code into Xen[0]. >> > = >> > In the meantime we defer this to Dom0. >> > = >> > I wonder though if it would be possible to manage the clocks for a >> > passthrough device from the toolstack, i.e. is there a sysfs node where >> > one >> > can say "keep the clock for this device enabled (at xMhz) even though >> > you >> > think the device is unused"? >> = >> I am afraid not. The linux device driver without xen can work well, >> because >> there is clk tree and "clk_get,clk_prepare,clk_set_rate" work well in the >> driver. >> I do not want to remove the clk apis usage from the device driver for >> xen, because the driver >> also serves when no xen support. The pvclk interface is mainly to let the >> clk api can work as no xen. > >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. 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 cl= ock, we need to expose the clk info to userspace. Jan said using hypercall in the other mail, do you have any ideas about thi= s? Thanks, Peng. > >Ian. > >[0] Documentation/devicetree/bindings/clock/fixed-clock.txt >