Re: Stabilising some tools only HVMOPs?

[Wei Liu <wei.liu2@citrix.com>]

On Thu, Feb 18, 2016 at 10:53:00AM +0000, Ian Campbell wrote:
> On Thu, 2016-02-18 at 10:45 +0000, Wei Liu wrote:
> > On Thu, Feb 18, 2016 at 03:37:06AM -0700, Jan Beulich wrote:
> > > > > > On 18.02.16 at 11:24, <ian.campbell@citrix.com> wrote:
> > > > On Wed, 2016-02-17 at 17:28 +0000, Wei Liu wrote:
> > > > > 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'm curious about the rationale for making them tools only in the
> > > > > first place and what needs to be done to make them stable.
> > > > 
> > > > FWIW (IMHO, YMMV etc) it is becoming increasing incorrect to consider
> > > > the
> > > > device model as "tools" in the face of disaggregation and support for
> > > > (nearly) arbitrary upstream QEMU versions etc.
> > > 
> > > As just written in the other reply, it depends on what exactly
> > > qemu uses: libxc interfaces are fine, since the "tools only"
> > > aspect in the public headers is mainly to allow us to alter
> > > structure layouts and alike. The "tools only" aspect there in
> > > particular is not to preclude entities like qemu (indirectly)
> > > invoking such operations - that's instead being dealt with by
> > > permission checks.
> > > 
> > > I.e. as long a qemu doesn't define __XEN_TOOLS__ for its
> > > building, I think we're fine.
> > > 
> > 
> > OK, so you're suggesting building stable APIs on top of unstable ones.
> > 
> > That's doable but undesirable. Once libxendevicemodel APIs are set in
> > stone they need to be supported in the long run. The underlying
> > hypervisor structure can change, but they still need to support the
> > upper layer one way or another. We may as well think hard now to get
> > things correct.
> 
> FWIW I think it is important that any API/ABI stable interfaces are not
> supplied as part of the otherwise unstable libxenctrl/libxenguest pair --
> just to avoid any confusion or misunderstanding regarding what is or is not
> considered stable.
> 

Agreed.  Whichever route we take, there will be no APIs left in
libxenctrl and libxenguest pair.

Wei.

> Ian.
>