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:59:23 +0000 Message-ID: <20160218105923.GF3723@citrix.com> References: <20160217172808.GB3723@citrix.com> <56C5ABA502000078000D3982@prv-mh.provo.novell.com> <1455792278.6225.27.camel@citrix.com> <56C5B13802000078000D3A0A@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.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aWML9-0001Qy-Ls for xen-devel@lists.xenproject.org; Thu, 18 Feb 2016 11:01:43 +0000 Content-Disposition: inline In-Reply-To: <56C5B13802000078000D3A0A@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 , IanJackson , PaulDurrant , Anthony PERARD , Xen-devel List-Id: xen-devel@lists.xenproject.org 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. Wei. > Jan >