Re: Stabilising some tools only HVMOPs?

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

On Thu, Feb 18, 2016 at 03:55:36AM -0700, Jan Beulich wrote:
> >>> On 18.02.16 at 11:44, <ian.campbell@citrix.com> wrote:
> > On Thu, 2016-02-18 at 03:31 -0700, Jan Beulich wrote:
> >> > > > 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.
> > 
> > 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).
> 

Right. I think the misunderstanding stems from the fact that
__XEN_TOOLS__ conflates two aspects -- only used by tools and not stable.

I think we still need the first property (only used by tools) but not
the second.

Wei.

> Jan
>