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 09:56:24 +0800 Message-ID: <20160122015622.GD29399@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> <56A0BF4202000078000C980B@prv-mh.provo.novell.com> <20160121120615.GB29399@linux-7smt.suse> <56A0E28C02000078000C995C@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.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aMR1K-0000FJ-5r for xen-devel@lists.xenproject.org; Fri, 22 Jan 2016 02:00:14 +0000 Received: by mail-pf0-f193.google.com with SMTP id 65so2575356pfd.1 for ; Thu, 21 Jan 2016 18:00:12 -0800 (PST) Content-Disposition: inline In-Reply-To: <56A0E28C02000078000C995C@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 Thu, Jan 21, 2016 at 05:52:12AM -0700, Jan Beulich wrote: >>>> On 21.01.16 at 13:06, wrote: >> On Thu, Jan 21, 2016 at 03:21:38AM -0700, Jan Beulich wrote: >>>>>> On 21.01.16 at 09:59, wrote: >>>> uart2 needs clock IMX7D_UART2_ROOT_CLK from the ccm. >>>> passthrough uart2, hypervisor handles the reg and interrupts, that is >>>> because >>>> hypervisor handles the memory map and the interrupt controller(GIC). But >>>> here >>>> CCM is not handled by hypervisor, it is handled by Dom0. >>> >>>This, I take it, describes the current state, which doesn't make clear >>>whether this is intentionally that way (and can't be changed), or >>>just happens to be that way because so far it didn't matter. >>> >>>> For ARMV8 server products, I am not sure whether hypercall is better; but to >>>> my case, it's not feasible to use hypercall. >>> >>>Because of ...? >> >> I guess you mean DomU issues hypercall and Xen forwards the request to Dom0, >> then Dom0 reply the response? > >Well, no, that wouldn't be a desirable (or even sane) model. > >>>> Dom0 handles all the clocks, DomU just send request to Dom0 and ask Dom0 to >>>> enable/disable/set rate for a clock for the device. So I think it's okay >>>> for multipile parties, the clk subsystem in Dom0 can handle mutiple requests >>>> even if the clock is shared. >>> >>>I.e. if one party sets one rate, and later another party sets >>>a different rate, things are going to work fine? If so, why would >>>the different parties need control over the rate in the first place? >> >> oh. thanks for teaching me. If two IPs share one clock, and IP1 for Dom0, >> IP2 for DomU, >> Dom0 needs clock work at 20Hz, but DomU want clock work at 40Hz. pvclk can >> not avoid this. > >But you mustn't allow a DomU to affect Dom0, nor may two DomU-s >interact in such a way with one another. > >> If not using pvclk, we develop a new method to handle clock. I guest we can >> also not avoid this? > >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? If the pvclk interface is not desirable, I have no more idea on this for now(: Thanks, Peng. > >Jan >