From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@suse.com>
Subject: Re: [RFC V2] xen: interface: introduce pvclk interface
Date: Fri, 22 Jan 2016 00:36:31 -0700
Message-ID: <56A1EA0F02000078000C9DE2@prv-mh.provo.novell.com>
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>
	<20160122015622.GD29399@linux-7smt.suse>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1aMWGo-0002mU-Dd
	for xen-devel@lists.xenproject.org; Fri, 22 Jan 2016 07:36:34 +0000
In-Reply-To: <20160122015622.GD29399@linux-7smt.suse>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Peng Fan <van.freenix@gmail.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>, Julien Grall <julien.grall@citrix.com>, David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xenproject.org
List-Id: xen-devel@lists.xenproject.org

>>> On 22.01.16 at 02:56, <van.freenix@gmail.com> wrote:
> On Thu, Jan 21, 2016 at 05:52:12AM -0700, Jan Beulich wrote:
>>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?

Userspace would be fine, but
- How would this fit in your frontend/backend model, where
  userspace shouldn't be involved at all?
- Libxl may be a little too high up the stack, libxc would seem a
  more appropriate place to me (but that's subject to tools
  maintainers disagreeing with me).

Jan