[Xen-devel] Domctl and physdevop for passthrough (Was: Re: Stabilising some tools only HVMOPs?)

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.02.16 at 17:05, <wei.liu2@xxxxxxxxxx> wrote:
> On Wed, Feb 17, 2016 at 05:28:08PM +0000, Wei Liu 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
>> 
> 
> In the process of ploughing through QEMU symbols, there are some domctls
> and physdevops used to do  passthrough. To make passthrough APIs in
> libxendevicemodel we need to stabilise them as well. Can I use the same
> trick __XEN_TOOLS_STABLE__ here? If not, what would be the preferred way
> of doing this?
> 
> PASSTHRU
> `xc_domain_bind_pt_pci_irq`     `XEN_DOMCTL_bind_pt_irq`    
> `xc_domain_ioport_mapping`      `XEN_DOMCTL_ioport_mapping` 
> `xc_domain_memory_mapping`      `XEN_DOMCTL_memory_mapping` 
> `xc_domain_unbind_msi_irq`      `XEN_DOMCTL_unbind_pt_irq`  
> `xc_domain_unbind_pt_irq`       `XEN_DOMCTL_unbind_pt_irq`  
> `xc_domain_update_msi_irq`      `XEN_DOMCTL_bind_pt_irq`    
> `xc_physdev_map_pirq`           `PHYSDEVOP_map_pirq`        
> `xc_physdev_map_pirq_msi`       `PHYSDEVOP_map_pirq`        
> `xc_physdev_unmap_pirq`         `PHYSDEVOP_unmap_pirq`      

Mechanically I would say yes, but anything here which is also on
the XSA-77 waiver list would first need removing there (with
proper auditing and, if necessary, fixing).

Jan


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