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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.02.16 at 13:23, <wei.liu2@xxxxxxxxxx> wrote:
> On Tue, Feb 23, 2016 at 02:31:30PM +0000, Wei Liu wrote:
>> 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 conversation thus far has indicated stabilising this particular
> hypercall is no go.
> 
> The higher order goal is actually pinning the memory cache attribute for
> video ram. I was thinking to have a set of dedicated hypercalls for
> video ram.
> 
> But then my reading of XSA-154 suggests that no untrusted entity should
> be allowed to alter the caching attribute, so a set of restricted
> hypercalls might not be feasible either. I would like to know if my
> reading is correct.

Yes, your reading is mostly correct: Of course this can be
permitted eventually, but only after having made such a model
safe against abuse.

Jan


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