Re: [Xen-devel] Stabilising some tools only HVMOPs?

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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@xxxxxxxxxx> 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.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel