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:36:28 +0000 Message-ID: <20160218103628.GC3723@citrix.com> References: <20160217172808.GB3723@citrix.com> <56C5ABA502000078000D3982@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 1aWLwn-0006qI-H6 for xen-devel@lists.xenproject.org; Thu, 18 Feb 2016 10:36:33 +0000 Content-Disposition: inline In-Reply-To: <56C5ABA502000078000D3982@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: Wei Liu , Ian Campbell , Stefano Stabellini , Andrew Cooper , Ian Jackson , PaulDurrant , Anthony PERARD , Xen-devel List-Id: xen-devel@lists.xenproject.org On Thu, Feb 18, 2016 at 03:31:49AM -0700, Jan Beulich wrote: > >>> On 17.02.16 at 18:28, wrote: > > Hi all > > > > Tools people are in the process of splitting libxenctrl into a set of > > stable libraries. One of the proposed libraries is libxendevicemodel > > which has a collection of APIs that can be used by device model. > > > > Currently we use QEMU as reference to extract symbols and go through > > them one by one. Along the way we discover QEMU is using some tools > > only HVMOPs. > > > > 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've just grep-ed both qemu trees, and neither appears to directly > use any of these constants. So as long as qemu's use is solely > through libxc interfaces, I don't see an immediate issue. > > > 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. > > Qemu, in the original consideration, may also have been deemed > part of the tools. > > > The option to build stable library APIs on top of unstable hypervisor > > APIs is always there, but that looks suboptimal to me. > > Well, as long as we continue to tie libxc to the hypervisor version, > I think hiding versioning issues there would be fine. > I think you missed the first part of my email -- we are trying to split part of libxc out to make it stable. Ian's reply in a sibling thread has made clear the rationale behind this. Libxc is still tied to hypervisor, but the libraries that we split out are stable. Wei. > Jan >