From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: Stabilising some tools only HVMOPs? Date: Thu, 18 Feb 2016 10:55:02 +0000 Message-ID: <20160218105502.GE3723@citrix.com> References: <20160217172808.GB3723@citrix.com> <1455791058.6225.19.camel@citrix.com> <56C5ACE202000078000D3999@prv-mh.provo.novell.com> <20160218104526.GD3723@citrix.com> <1455792780.6225.29.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aWMEl-0000nv-3x for xen-devel@lists.xenproject.org; Thu, 18 Feb 2016 10:55:07 +0000 Content-Disposition: inline In-Reply-To: <1455792780.6225.29.camel@citrix.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: Ian Campbell Cc: Wei Liu , Stefano Stabellini , Andrew Cooper , Ian Jackson , Paul Durrant , Jan Beulich , Anthony PERARD , Xen-devel List-Id: xen-devel@lists.xenproject.org On Thu, Feb 18, 2016 at 10:53:00AM +0000, Ian Campbell wrote: > On Thu, 2016-02-18 at 10:45 +0000, Wei Liu wrote: > > On Thu, Feb 18, 2016 at 03:37:06AM -0700, Jan Beulich wrote: > > > > > > On 18.02.16 at 11:24, wrote: > > > > On Wed, 2016-02-17 at 17:28 +0000, Wei Liu wrote: > > > > > The list of tools only HVMOPs used by QEMU are: > > > > > = > > > > > =A0 #define HVMOP_track_dirty_vram=A0=A0=A0=A06 > > > > > =A0 #define HVMOP_modified_memory=A0=A0=A0=A07 > > > > > =A0 #define HVMOP_set_mem_type=A0=A0=A0=A08 > > > > > =A0 #define HVMOP_inject_msi=A0=A0=A0=A0=A0=A0=A0=A0=A016 > > > > > =A0 #define HVMOP_create_ioreq_server 17 > > > > > =A0 #define HVMOP_get_ioreq_server_info 18 > > > > > =A0 #define HVMOP_map_io_range_to_ioreq_server 19 > > > > > =A0 #define HVMOP_unmap_io_range_from_ioreq_server 20 > > > > > =A0 #define HVMOP_destroy_ioreq_server 21 > > > > > =A0 #define HVMOP_set_ioreq_server_state 22 > > > > > = > > > > > I'm curious about the rationale for making them tools only in the > > > > > first place and what needs to be done to make them stable. > > > > = > > > > FWIW (IMHO, YMMV etc) it is becoming increasing incorrect to consid= er > > > > the > > > > device model as "tools" in the face of disaggregation and support f= or > > > > (nearly) arbitrary upstream QEMU versions etc. > > > = > > > As just written in the other reply, it depends on what exactly > > > qemu uses: libxc interfaces are fine, since the "tools only" > > > aspect in the public headers is mainly to allow us to alter > > > structure layouts and alike. The "tools only" aspect there in > > > particular is not to preclude entities like qemu (indirectly) > > > invoking such operations - that's instead being dealt with by > > > permission checks. > > > = > > > I.e. as long a qemu doesn't define __XEN_TOOLS__ for its > > > building, I think we're fine. > > > = > > = > > OK, so you're suggesting building stable APIs on top of unstable ones. > > = > > That's doable but undesirable. Once libxendevicemodel APIs are set in > > stone they need to be supported in the long run. The underlying > > hypervisor structure can change, but they still need to support the > > upper layer one way or another. We may as well think hard now to get > > things correct. > = > FWIW I think it is important that any API/ABI stable interfaces are not > supplied as part of the otherwise unstable libxenctrl/libxenguest pair -- > just to avoid any confusion or misunderstanding regarding what is or is n= ot > considered stable. > = Agreed. Whichever route we take, there will be no APIs left in libxenctrl and libxenguest pair. Wei. > Ian. > =