Domctl and physdevop for passthrough (Was: Re: Stabilising some tools only HVMOPs?)

From: "Jan Beulich" <JBeulich@suse.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	PaulDurrant <Paul.Durrant@citrix.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Domctl and physdevop for passthrough (Was: Re: Stabilising some tools only HVMOPs?)
Date: Mon, 22 Feb 2016 04:28:19 -0700	[thread overview]
Message-ID: <56CAFEE302000078000D4A74@prv-mh.provo.novell.com> (raw)
In-Reply-To: <20160219160539.GV3723@citrix.com>

>>> On 19.02.16 at 17:05, <wei.liu2@citrix.com> 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