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 04:04:42 -0700 Message-ID: <56C5B35A02000078000D3A4E@prv-mh.provo.novell.com> References: <20160217172808.GB3723@citrix.com> <56C5ABA502000078000D3982@prv-mh.provo.novell.com> <1455792278.6225.27.camel@citrix.com> <56C5B13802000078000D3A0A@prv-mh.provo.novell.com> <20160218105923.GF3723@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 1aWN8m-0005Fs-Ih for xen-devel@lists.xenproject.org; Thu, 18 Feb 2016 11:53:00 +0000 In-Reply-To: <20160218105923.GF3723@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 , IanJackson , PaulDurrant , Anthony PERARD , Xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 18.02.16 at 11:59, wrote: > On Thu, Feb 18, 2016 at 03:55:36AM -0700, Jan Beulich wrote: >> >>> On 18.02.16 at 11:44, wrote: >> > On Thu, 2016-02-18 at 03:31 -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. >> > >> > The point is that we want to stop QEMU using libxc and instead make it use >> > the proposed libxendevicemodel which will provide a stable interface to the >> > Xen functionality required by QEMU (like I recently did for evtchn, gnttab >> > and privcmd functionality). >> >> In that case I'm afraid we indeed need to make those interfaces >> stable, by introducing a new group: Stuff that's stable but not to >> be exposed to guests (albeit this non-exposure is of course only >> an aid to people writing guest side code, to not tempt them to use >> what won't work from inside a guest anyway, and hence isn't >> strictly needed). >> > > Right. I think the misunderstanding stems from the fact that > __XEN_TOOLS__ conflates two aspects -- only used by tools and not stable. > > I think we still need the first property (only used by tools) but not > the second. I agree on both points. Jan