From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Domctl and physdevop for passthrough (Was: Re: Stabilising some tools only HVMOPs?) Date: Mon, 22 Feb 2016 04:28:19 -0700 Message-ID: <56CAFEE302000078000D4A74@prv-mh.provo.novell.com> References: <20160217172808.GB3723@citrix.com> <20160219160539.GV3723@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aXofE-00045i-8l for xen-devel@lists.xenproject.org; Mon, 22 Feb 2016 11:28:28 +0000 In-Reply-To: <20160219160539.GV3723@citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: Ian Campbell , Stefano Stabellini , Andrew Cooper , Ian Jackson , PaulDurrant , Anthony PERARD , Xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 19.02.16 at 17:05, 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