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:55:36 -0700 Message-ID: <56C5B13802000078000D3A0A@prv-mh.provo.novell.com> References: <20160217172808.GB3723@citrix.com> <56C5ABA502000078000D3982@prv-mh.provo.novell.com> <1455792278.6225.27.camel@citrix.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 1aWMFK-0000tD-C2 for xen-devel@lists.xenproject.org; Thu, 18 Feb 2016 10:55:42 +0000 In-Reply-To: <1455792278.6225.27.camel@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: Ian Campbell , Wei Liu Cc: Stefano Stabellini , Andrew Cooper , IanJackson , PaulDurrant , Anthony PERARD , Xen-devel List-Id: xen-devel@lists.xenproject.org >>> 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). Jan