Re: Stabilising some tools only HVMOPs?

["Jan Beulich" <JBeulich@suse.com>]

>>> 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).

Jan