On Thu, 2016-02-18 at 03:31 -0700, Jan Beulich wrote: > > > > On 17.02.16 at 18:28, <wei.l...@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). 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@lists.xen.org http://lists.xen.org/xen-devel
