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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Feb 22, 2016 at 04:28:19AM -0700, Jan Beulich wrote:
> >>> 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).
> 

I admit I failed to parse xsm-flask.txt and XSA-77 and its implication,
so let's take a concrete example instead.

Say, now I need to stabilise XEN_DOMCTL_pin_mem_cacheattr, which is on
the list of domctls listed in xsm-flask.txt (presumably that's the
waiver list you talked about).

You said "needs removing there", and xsm-flask.txt says "suops not
listed here are considered safe for disaggregation", so the implication
is that we need to make XEN_DOMCTL_pin_mem_cacheattr safe for
disaggregation in order to move it off the list. Is this correct?

And in order to make it safe for disaggregation, I need to add adequate
XSM checks for it. Is this correct?

Wei.

> Jan
> 

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