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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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.

Wei.

> Jan
> 

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