From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@suse.com>
Subject: Re: Stabilising some tools only HVMOPs?
Date: Thu, 18 Feb 2016 03:31:49 -0700
Message-ID: <56C5ABA502000078000D3982@prv-mh.provo.novell.com>
References: <20160217172808.GB3723@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1aWLsI-000637-37
	for xen-devel@lists.xenproject.org; Thu, 18 Feb 2016 10:31:54 +0000
In-Reply-To: <20160217172808.GB3723@citrix.com>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, PaulDurrant <Paul.Durrant@citrix.com>, Anthony PERARD <anthony.perard@citrix.com>, Xen-devel <xen-devel@lists.xenproject.org>
List-Id: xen-devel@lists.xenproject.org

>>> On 17.02.16 at 18:28, <wei.liu2@citrix.com> 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.

Jan