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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

I agree on both points.

Jan


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