From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Stabilising some tools only HVMOPs? Date: Thu, 18 Feb 2016 03:56:20 -0700 Message-ID: <56C5B16402000078000D3A0D@prv-mh.provo.novell.com> References: <20160217172808.GB3723@citrix.com> <1455791058.6225.19.camel@citrix.com> <56C5ACE202000078000D3999@prv-mh.provo.novell.com> <20160218104526.GD3723@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aWMG0-0000zu-5r for xen-devel@lists.xenproject.org; Thu, 18 Feb 2016 10:56:24 +0000 In-Reply-To: <20160218104526.GD3723@citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: Ian Campbell , Stefano Stabellini , Andrew Cooper , Ian Jackson , Paul Durrant , Anthony PERARD , Xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 18.02.16 at 11:45, 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: >> >> >> >> #define HVMOP_track_dirty_vram 6 >> >> #define HVMOP_modified_memory 7 >> >> #define HVMOP_set_mem_type 8 >> >> #define HVMOP_inject_msi 16 >> >> #define HVMOP_create_ioreq_server 17 >> >> #define HVMOP_get_ioreq_server_info 18 >> >> #define HVMOP_map_io_range_to_ioreq_server 19 >> >> #define HVMOP_unmap_io_range_from_ioreq_server 20 >> >> #define HVMOP_destroy_ioreq_server 21 >> >> #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 consider the >> > device model as "tools" in the face of disaggregation and support for >> > (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. No, sorry, I'm not, after having read your and Ian's earlier replies. Jan