Re: [Xen-devel] [PATCH v2 08/11] IOMMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (leaf ones).

["Xu, Quan" <quan.xu@xxxxxxxxx>]

On April 26, 2016 8:52 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >>> On 26.04.16 at 13:50, <quan.xu@xxxxxxxxx> wrote:
> > On April 25, 2016 7:40 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >> >>> On 18.04.16 at 16:00, <quan.xu@xxxxxxxxx> wrote:
> >> > While IOMMU Device-TLB flush timed out, xen calls panic() at present.
> >> > However the existing panic() is going to be eliminated, so we must
> >> > propagate the IOMMU Device-TLB flush error up to the
> >> > iommu_iotlb_flush{,_all}.
> >> >
> >> > If IOMMU mapping and unmapping failed, the domain (with the
> >> > exception of the hardware domain) is crashed, treated as a fatal
> >> > error. Rollback can be lighter weight.
> >> >
> >> > This patch fixes the leaf ones.
> >> >
> >> > Signed-off-by: Quan Xu <quan.xu@xxxxxxxxx>
> >>
> >> Looks okay except for the again missing uses of __must_check on
> >> function declarations or, where needed, definitions.
> >
> > This patch modifies the common part  'iommu_ops', but not to fix the
> > ARM/AMD callbacks ( it seems the callbacks are not initialized for AMD
> > code, but ARM does).
> > I need to fix ARM callbacks as well.
> >
> >
> >  I wonder whether it is good to use  __must_check on these callbacks or not.
> 
> For callbacks it's indeed questionable.
> 


I think so.


> >  IMO I'd better use __must_check on functions, i.e.
> > iommu_iotlb_flush_all(),  invoking these callbacks,  instead of these
> callbacks.
> 
> At least the two functions in xen/drivers/passthrough/iommu.c that this
> patch alters need to gain __must_check annotations (if they don't already in
> an earlier patch - that's simply not possible to tell on this version, which 
> fails to
> add any such annotations).
> 

I didn't add __must_check annotations in v2.
I will consider __must_check annotations carefully in next v3. 

Quan

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