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 22:05:52 +0800 Message-ID: <20160120140550.GB10911@linux-7smt.suse> References: <1453278682-8750-1-git-send-email-van.freenix@gmail.com> <569F6C0C02000078000C8F2C@prv-mh.provo.novell.com> <20160120114054.GA9856@linux-7smt.suse> <569F853402000078000C9038@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aLtPO-0004O9-17 for xen-devel@lists.xenproject.org; Wed, 20 Jan 2016 14:06:50 +0000 Received: by mail-pa0-f44.google.com with SMTP id yy13so5232640pab.3 for ; Wed, 20 Jan 2016 06:06:48 -0800 (PST) Content-Disposition: inline In-Reply-To: <569F853402000078000C9038@prv-mh.provo.novell.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: Jan Beulich Cc: Ian Campbell , Stefano Stabellini , George Dunlap , Julien Grall , David Vrabel , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org Hi Jan, On Wed, Jan 20, 2016 at 05:01:40AM -0700, Jan Beulich wrote: >>>> On 20.01.16 at 12:40, wrote: >> Hi Jan, >> >> On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wrote: >>>>>> On 20.01.16 at 09:31, wrote: >>>> +/* >>>> + * 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. >>>> + * 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. >>>> + */ >>>> +struct xen_clkif_response { >>>> + uint32_t cmd; >>>> + uint32_t id; >>>> + uint32_t success; >>>> + uint64_t rate; >>>> +}; >>> >>>This isn't 32-/64-bit clean. Question is whether echoing cmd is really >>>needed. >> >> As Juergen suggested, use a request id. I'll fix this in V3. >> 32-/64-bit unclean, I can not get you here (: > >The layout of above structure may end up different for 32- and >64-bit guests, depending on the alignment of uint64_t. Thanks for teaching me. In V3, the layout will be changed to like this struct xen_clkif_response { uint32_t request_id; int32_t status; uint64_t rate; }; And more macro definitions for the status entry: #define XEN_CLK_OP_SUCCESS 0 #define XEN_CLK_ENABLE_FALIURE -1 #define XEN_CLK_DISABLE_FAILURE -2 #define XEN_CLK_PREPARE_FAILURE -3 #define XEN_CLK_UNPREPARE_FAILURE -4 #define XEN_CLK_SET_RATE_FAILURE -5 #define XEN_CLK_GET_RATE_FALIURE -6 > >>>And what I'm missing throughout the file is some description of how >>>clock events (interrupts?) are actually meant to make it into the >>>guest. >> >> I have a simple implementation v1 patch for linux, >> http://lists.xen.org/archives/html/xen-devel/2016-01/msg01860.html. >> You can see how it works. > >No, sorry, that's not the point of the inquiry. It seems to me that >there are more aspects to this interface, not directly related to >the request/reply protocol written down here, which need to be >spelled out event if they don't require any particular definitions >or type declarations. I try to follow you about clock events(interrupts?), not sure whether I understand correct or not. clock in this file is the clk for a device. In linux side, it managed by clk subsystem, drivers/clk/xx. This is not the clock events or clock source in drivers/clocksource/xx. For the pvclk interface, there will be no interrupt for the guest. I'll add more texts in the file or commit log. Thanks, Peng. > >Jan >