From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peng Fan Subject: Re: [RFC V2] xen: interface: introduce pvclk interface Date: Wed, 20 Jan 2016 19:48:00 +0800 Message-ID: <20160120114759.GB9856@linux-7smt.suse> References: <1453278682-8750-1-git-send-email-van.freenix@gmail.com> <569F4DCB.2030701@suse.com> <20160120092546.GA9107@linux-7smt.suse> <569F6437.5000501@suse.com> 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 1aLrG2-0000nN-6b for xen-devel@lists.xenproject.org; Wed, 20 Jan 2016 11:49:02 +0000 Received: by mail-pf0-f177.google.com with SMTP id q63so3833350pfb.1 for ; Wed, 20 Jan 2016 03:49:00 -0800 (PST) Content-Disposition: inline In-Reply-To: <569F6437.5000501@suse.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: Juergen Gross Cc: Ian Campbell , Stefano Stabellini , George Dunlap , Julien Grall , David Vrabel , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org Hi Juergen, On Wed, Jan 20, 2016 at 11:40:55AM +0100, Juergen Gross wrote: >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. Will change this to `int status`, as also observed by Jan. I'll also define macros such as "#define XEN_CLK_ENABLE_OK 0", "#define XEN_CLK_ENABLE_FAILURE -1" > >>>> + * 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. Thanks for teaching me on this. So the request id should be globally unique for backend. So "random value(generated in frontend) + frontend domid" is ok for this? Thanks, Peng. > > >juergen