From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [RFC V2] xen: interface: introduce pvclk interface Date: Thu, 21 Jan 2016 05:52:12 -0700 Message-ID: <56A0E28C02000078000C995C@prv-mh.provo.novell.com> 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> <56A0BF4202000078000C980B@prv-mh.provo.novell.com> <20160121120615.GB29399@linux-7smt.suse> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aMEir-0005Fz-07 for xen-devel@lists.xenproject.org; Thu, 21 Jan 2016 12:52:21 +0000 In-Reply-To: <20160121120615.GB29399@linux-7smt.suse> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Peng Fan Cc: Ian Campbell , Stefano Stabellini , George Dunlap , Julien Grall , David Vrabel , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org >>> 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. Jan