From mboxrd@z Thu Jan  1 00:00:00 1970
From: Juergen Gross <jgross@suse.com>
Subject: Re: [RFC V2] xen: interface: introduce pvclk interface
Date: Wed, 20 Jan 2016 11:40:55 +0100
Message-ID: <569F6437.5000501@suse.com>
References: <1453278682-8750-1-git-send-email-van.freenix@gmail.com>
	<569F4DCB.2030701@suse.com> <20160120092546.GA9107@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.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1aLqCG-0005kn-AX
	for xen-devel@lists.xenproject.org; Wed, 20 Jan 2016 10:41:04 +0000
In-Reply-To: <20160120092546.GA9107@linux-7smt.suse>
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 20/01/16 10:25, Peng Fan wrote:
> Hi Juergen,
> 
> On Wed, Jan 20, 2016 at 10:05:15AM +0100, Juergen Gross wrote:
>> On 20/01/16 09:31, Peng Fan wrote:
>>> Introduce pvclk interface which is useful when doing device passthrough
>>> on ARM platform.
>>
>> ...
>>
>>> +/*
>>> + * Frontend request
>>> + *
>>> + * cmd: command for operation on clk, should be XEN_CLK_[xx],
>>> + *	excluding XEN_CLK_END. id is the
>>> + * id: clk id
>>> + * rate: clock rate. Used for set rate.
>>
>> Which unit? Hz?
> 
> Yeah. Hz. I'll add comments in V3.
> 
>>
>>> + */
>>> +struct xen_clkif_request {
>>> +	uint32_t cmd;
>>> +	uint32_t id;
>>> +	uint64_t rate;
>>> +};
>>> +typedef struct xen_clkif_request xen_clkif_request_t;
>>> +
>>> +/*
>>> + * Backend response
>>> + *
>>> + * cmd: command for operation on clk, same with the cmd in request.
>>> + * id: clk id, same with the id in request.
>>> + * success: indicate failure or success for the cmd.
>>
>> Values?
> 
> I'd like to let the frontend/backend driver to determine the value.
> In my implementation for linux, if the backend API supports return value,
> I'll fill the return value to success entry. If the backend API returns
> void, I'll just fill 0 to success entry.

So please specify "0" to mean success and add some sensible error
values. There might be multiple frontend- and/or backend-variants which
all must agree using the same interface.

>>> + * rate: clock rate. Used for get rate.
>>> + *
>>> + * cmd and id are filled by backend and passed to frontend to
>>> + * let frontend check whether the response is for the current
>>> + * request or not.
>>
>> I'd rather let the frontend add a request Id to the request which
>> will be echoed here instead cmd and clock Id.
> 
> If using request id, I think we can encode cmd and id into request id?

This should just be an opaque value for the backend. The frontend is
free how to create this value, it should be unique for every outstanding
request of a domU, however. It could be built from cmd and id in case
there can't be multiple requests with the same cmd/id combination
active in a domU.


juergen