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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2016-02-18 at 03:31 -0700, Jan Beulich wrote:
> > > > On 17.02.16 at 18:28, <wei.liu2@xxxxxxxxxx> 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).

At the moment distros need to rebuild their QEMU whenever Xen is upgraded
to link against a new libxc, which introduces an annoying lockstep for
them.

It also breaks e.g. Debian's arrangements which allow for multiple
tools+hypervisors to be installed and selecting tools to match the booted
hypervisor.

> > The option to build stable library APIs on top of unstable hypervisor
> > APIs is always there, but that looks suboptimal to me.
> 
> Well, as long as we continue to tie libxc to the hypervisor version,
> I think hiding versioning issues there would be fine.
> 
> Jan
> 

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