Re: [PATCH 11/12] swiotlb: merge swiotlb-xen initialization into swiotlb

[Christoph Hellwig <hch@xxxxxx>]

On Tue, Mar 01, 2022 at 06:55:47PM -0800, Stefano Stabellini wrote:
> Unrelated to this specific patch series: now that I think about it, if
> io_tlb_default_mem.nslabs is already allocated by the time xen_mm_init
> is called, wouldn't we potentially have an issue with the GFP flags used
> for the earlier allocation (e.g. GFP_DMA32 not used)? Maybe something
> for another day.

swiotlb_init allocates low memory from meblock, which is roughly
equivalent to GFP_DMA allocations, so we'll be fine.

> > @@ -143,10 +141,15 @@ static int __init xen_mm_init(void)
> >     if (!xen_swiotlb_detect())
> >             return 0;
> >  
> > -   rc = xen_swiotlb_init();
> >     /* we can work with the default swiotlb */
> > -   if (rc < 0 && rc != -EEXIST)
> > -           return rc;
> > +   if (!io_tlb_default_mem.nslabs) {
> > +           if (!xen_initial_domain())
> > +                   return -EINVAL;
> 
> I don't think we need this xen_initial_domain() check. It is all
> already sorted out by the xen_swiotlb_detect() check above.

Is it?

static inline int xen_swiotlb_detect(void)
{
        if (!xen_domain())
                return 0;
        if (xen_feature(XENFEAT_direct_mapped))
                return 1;
        /* legacy case */
        if (!xen_feature(XENFEAT_not_direct_mapped) && xen_initial_domain())
                return 1;
        return 0;
}

I think I'd keep it as-is for now, as my planned next step would be to
fold xen-swiotlb into swiotlb entirely.