Re: [PATCH v2 0/3][4.16] x86/IOMMU: enabled / intremap handling

[Ian Jackson <iwj@xxxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [PATCH v2 0/3][4.16] x86/IOMMU: enabled / intremap 
handling"):
> > Reviewed-by: Ian Jackson <iwj@xxxxxxxxxxxxxx>
> > 
> >> Patch 2 corrects an (unlikely but not impossible to be taken) error
> >> path, supposedly making systems functional again in case they would
> >> in fact cause that error path to be taken. The risk looks low to me,
> >> given that two function calls with previously assumed to be
> >> identical results now get folded into one with the result latched.
> > 
> > This one also:
> > 
> > Release-Acked-by: Ian Jackson <iwj@xxxxxxxxxxxxxx>
> 
> Thanks, but your reply leaves me a little confused: Your use of "also"
> may mean R-b for both patches but R-a-b only for patch 2. But I could
> also find a variety of other interpretations, including that the
> first R-b really was meant to be R-a-b (which otherwise I'd need on
> top of the R-b anyway). Please clarify.

Um.  Well spotted.  I meant release-acked-by for both.  I botched the
keystroke in my MUA.  Sorry for the confusion.

So FTAAD I have *not* "Reviewed" either patch (although I did read it,
I don't consider myself qualified to give an R-b).

> > I think, from reading the thread, that patch 3 is not targeting 4.16.
> 
> Correct. The other related one now targeting 4.16 is the separately
> submitted "x86/x2APIC: defer probe until after IOMMU ACPI table
> parsing". But I can see reasons for you to prefer to have that
> deferred.

Thanks,
Ian.