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 19:55:12 +0800 Message-ID: <20160121115510.GA29399@linux-7smt.suse> References: <20160120114054.GA9856@linux-7smt.suse> <569F853402000078000C9038@prv-mh.provo.novell.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aME8e-00023d-UV for xen-devel@lists.xenproject.org; Thu, 21 Jan 2016 12:14:57 +0000 Received: by mail-pa0-f42.google.com with SMTP id ho8so22447983pac.2 for ; Thu, 21 Jan 2016 04:14:55 -0800 (PST) Content-Disposition: inline In-Reply-To: <1453371572.26343.210.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 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 d= river. 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 c= lk api can work as no xen. Introduce pvclk may introduce more stuff, I have no more idea for now, = if want to let the device driver unchanged and work well for passed through= device. (: > >If so (or if it can be easily added) then the toolstack would just need to >manage that value as part of the passthrough process rather than having the >frontend do it via a PV protocol. > >Ian. > >[0] I'd like at some point for Xen to gain sufficient knowledge of clock IP >to minimally control things like the CPU and DRAM clocks etc, but that >needn't imply full clock tree support and would hopefully be a manageable >amount of code, which would (hopefully) mostly be about trapping and >emulating writes to one or two clock controllers per platform and >arbitrating a small set of bits (while allowing dom0 to control the >others). This is at least a medium if not long term idea though, and for >all I know it might turn out to be unworkable in practice. I am happy to see that if one day, xen takes part of the clock management t= o minimize power usage. These few days, I also look into the power management of xen. seems it main= ly serves for x86. Let xen hypervisor handle cpu and dram clocks may be better than let dom0. Thanks, Peng. >