Re: [PATCH 2/2] x86/ACPI: Set swiotlb area according to the number of lapic entry in MADT
On 7/6/2022 5:02 PM, Christoph Hellwig wrote: On Wed, Jul 06, 2022 at 04:57:33PM +0800, Tianyu Lan wrote: 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(). Yes. The mem_init() is called before smp_init(). But why would that matter? cpu_possible_map is set up from setup_arch(), which is called before that. Sorry. I just still focus online cpu number and the number is got after smp_init(). Possible cpu number includes some offline cpus. I will have a try. Thanks for suggestion. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] x86/ACPI: Set swiotlb area according to the number of lapic entry in MADT
On Wed, Jul 06, 2022 at 04:57:33PM +0800, Tianyu Lan wrote: > 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(). Yes. > The mem_init() is called before smp_init(). But why would that matter? cpu_possible_map is set up from setup_arch(), which is called before that. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] x86/ACPI: Set swiotlb area according to the number of lapic entry in MADT
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. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] x86/ACPI: Set swiotlb area according to the number of lapic entry in MADT
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? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] x86/ACPI: Set swiotlb area according to the number of lapic entry in MADT
On 6/29/2022 10:04 PM, Christoph Hellwig wrote: On Mon, Jun 27, 2022 at 11:31:50AM -0400, Tianyu Lan wrote: From: Tianyu Lan When initialize swiotlb bounce buffer, smp_init() has not been called and cpu number can not be got from num_online_cpus(). Use the number of lapic entry to set swiotlb area number and keep swiotlb area number equal to cpu number on the x86 platform. 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. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] x86/ACPI: Set swiotlb area according to the number of lapic entry in MADT
On Mon, Jun 27, 2022 at 11:31:50AM -0400, Tianyu Lan wrote: > From: Tianyu Lan > > When initialize swiotlb bounce buffer, smp_init() has not been > called and cpu number can not be got from num_online_cpus(). > Use the number of lapic entry to set swiotlb area number and > keep swiotlb area number equal to cpu number on the x86 platform. Can we reorder that initialization? Because I really hate having to have an arch hook in every architecture. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
