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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.02.16 at 11:24, <ian.campbell@xxxxxxxxxx> wrote:
> On Wed, 2016-02-17 at 17:28 +0000, Wei Liu wrote:
>> 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'm curious about the rationale for making them tools only in the
>> first place and what needs to be done to make them stable.
> 
> FWIW (IMHO, YMMV etc) it is becoming increasing incorrect to consider the
> device model as "tools" in the face of disaggregation and support for
> (nearly) arbitrary upstream QEMU versions etc.

As just written in the other reply, it depends on what exactly
qemu uses: libxc interfaces are fine, since the "tools only"
aspect in the public headers is mainly to allow us to alter
structure layouts and alike. The "tools only" aspect there in
particular is not to preclude entities like qemu (indirectly)
invoking such operations - that's instead being dealt with by
permission checks.

I.e. as long a qemu doesn't define __XEN_TOOLS__ for its
building, I think we're fine.

Jan


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