[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |