Re: [PATCH 2/2] x86/ACPI: Set swiotlb area according to the number of lapic entry in MADT

[Tianyu Lan]

On 7/6/2022 4:00 PM, Christoph Hellwig wrote:
> On Fri, Jul 01, 2022 at 01:02:21AM +0800, Tianyu Lan wrote:
> > > Can we reorder that initialization?  Because I really hate having
> > > to have an arch hook in every architecture.
> >
> > How about using "flags" parameter of swiotlb_init() to pass area number
> > or add new parameter for area number?
> >
> > I just reposted patch 1 since there is just some coding style issue and area
> > number may also set via swiotlb kernel parameter. We still need figure out a
> > good solution to pass area number from architecture code.
>
> What is the problem with calling swiotlb_init after nr_possible_cpus()
> works?

Swiotlb_init() is called in the mem_init() of different architects and
memblock free pages are released to the buddy allocator just after
calling swiotlb_init() via memblock_free_all().

The mem_init() is called before smp_init(). If calling swiotlb_init()
after smp_init(), that means we can't allocate large chunk low end
memory via memblock_alloc() in the swiotlb(). Swiotlb_init() needs
to rework to allocate memory from the buddy allocator and just like
swiotlb_init_late() does. This will limit the bounce buffer size.
Otherwise We need to do the reorder for all achitectures and there maybe
some other unknown issues.

swiotlb flags parameter of swiotlb_init() seems to be a good place to
pass the area number in current code. If not set the swiotlb_area
number/flag, the area number will be one and keep the original behavior
of one single global spinlock protecting io tlb data structure.