Re: [Xen-devel] [PATCH v2 06/13] public / x86: introduce __HYPERCALL_iommu_op

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: George Dunlap [mailto:george.dunlap@xxxxxxxxxx]
> Sent: 11 July 2018 10:10
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; George Dunlap
> <George.Dunlap@xxxxxxxxxx>; Ian Jackson <Ian.Jackson@xxxxxxxxxx>; Jan
> Beulich <jbeulich@xxxxxxxx>; Konrad Rzeszutek Wilk
> <konrad.wilk@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; Tim
> (Xen.org) <tim@xxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>; Daniel De Graaf
> <dgdegra@xxxxxxxxxxxxx>
> Subject: Re: [PATCH v2 06/13] public / x86: introduce
> __HYPERCALL_iommu_op
> 
> On 07/07/2018 12:05 PM, Paul Durrant wrote:
> > +long do_iommu_op(unsigned int nr_bufs,
> > +                 XEN_GUEST_HANDLE_PARAM(xen_iommu_op_buf_t) bufs)
> > +{
> > +    unsigned int i;
> > +    long rc;
> > +
> > +    rc = xsm_iommu_op(XSM_PRIV, current->domain);
> 
> My only comment here is, doesn't this mean that XSM can only provide
> "yes/no" functionality for this entire hypercall, rather than being able
> to enable or disable individual operations?

That's true. I had not really considered the need to have finer grained 
control, but since you queried it, I'll re-work it so that it is possible to 
veto individual ops.

  Paul

> 
>  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel