RE: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

Hi, Thomas, > From: Thomas Gleixner > Sent: Sunday, December 12, 2021 8:12 AM > > Kevin, > > On Sat, Dec 11 2021 at 07:52, Kevin Tian wrote: > >> From: Jason Gunthorpe > >> > Then Qemu needs to find out the GSI number for the vIRTE handle. > >> > Again Qemu doesn't have such information since

RE: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

> From: Thomas Gleixner > Sent: Saturday, December 11, 2021 9:05 PM > > Kevin, > > On Sat, Dec 11 2021 at 07:44, Kevin Tian wrote: > >> From: Thomas Gleixner > >> On Fri, Dec 10 2021 at 08:39, Jason Gunthorpe wrote: > >> > It is clever, we don't have an vIOMMU that supplies vIR today, so by >

RE: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

Kevin, On Sat, Dec 11 2021 at 07:52, Kevin Tian wrote: >> From: Jason Gunthorpe >> > Then Qemu needs to find out the GSI number for the vIRTE handle. >> > Again Qemu doesn't have such information since it doesn't know >> > which MSI[-X] entry points to this handle due to no trap. >> >> No this

Re: [patch V3 12/35] soc: ti: ti_sci_inta_msi: Allocate MSI device data on first use

On Fri, Dec 10, 2021 at 11:19 PM Thomas Gleixner wrote: > > From: Thomas Gleixner > > Allocate the MSI device data on first invocation of the allocation function. > > Signed-off-by: Thomas Gleixner > Reviewed-by: Greg Kroah-Hartman > Reviewed-by: Jason Gunthorpe > Cc: Nishanth Menon > Cc:

Re: [patch V3 34/35] soc: ti: ti_sci_inta_msi: Get rid of ti_sci_inta_msi_get_virq()

On Fri, Dec 10, 2021 at 11:19 PM Thomas Gleixner wrote: > > From: Thomas Gleixner > > Just use the core function msi_get_virq(). > > Signed-off-by: Thomas Gleixner > Reviewed-by: Greg Kroah-Hartman > Reviewed-by: Jason Gunthorpe > Cc: Peter Ujfalusi > Cc: Vinod Koul > Cc:

Re: [patch V3 07/35] device: Move MSI related data into a struct

On Fri, Dec 10, 2021 at 11:18 PM Thomas Gleixner wrote: > > From: Thomas Gleixner > > The only unconditional part of MSI data in struct device is the irqdomain > pointer. Everything else can be allocated on demand. Create a data > structure and move the irqdomain pointer into it. The other MSI

Re: [patch V3 05/35] powerpc/cell/axon_msi: Use PCI device property

On Fri, Dec 10, 2021 at 11:18 PM Thomas Gleixner wrote: > > From: Thomas Gleixner > > instead of fiddling with MSI descriptors. > > Signed-off-by: Thomas Gleixner > Cc: Arnd Bergmann > Cc: Michael Ellerman > Cc: Benjamin Herrenschmidt > Cc: linuxppc-...@lists.ozlabs.org > --- Acked-by: Arnd

Re: [RFC PATCH v2 3/7] mm: migrate: allocate the right size of non hugetlb or THP compound pages.

Hi, On 2021/12/10 07:04, Zi Yan wrote: From: Zi Yan alloc_migration_target() is used by alloc_contig_range() and non-LRU movable compound pages can be migrated. Current code does not allocate the right page size for such pages. Check THP precisely using is_transparent_huge() and add

Re: [RFC PATCH v2 0/7] Use pageblock_order for cma and alloc_contig_range alignment.

Hi Zi Yan, On 2021/12/10 07:04, Zi Yan wrote: From: Zi Yan Hi all, This patchset tries to remove the MAX_ORDER - 1 alignment requirement for CMA and alloc_contig_range(). It prepares for my upcoming changes to make MAX_ORDER adjustable at boot time[1]. The MAX_ORDER - 1 alignment

Re: [RFC PATCH v2 4/7] mm: make alloc_contig_range work at pageblock granularity

Hi, On 2021/12/10 07:04, Zi Yan wrote: From: Zi Yan alloc_contig_range() worked at MAX_ORDER-1 granularity to avoid merging pageblocks with different migratetypes. It might unnecessarily convert extra pageblocks at the beginning and at the end of the range. Change alloc_contig_range() to work

Re: [RFC PATCH v2 1/7] mm: page_alloc: avoid merging non-fallbackable pageblocks with others.

Hi, On 2021/12/10 07:04, Zi Yan wrote: From: Zi Yan This is done in addition to MIGRATE_ISOLATE pageblock merge avoidance. It prepares for the upcoming removal of the MAX_ORDER-1 alignment requirement for CMA and alloc_contig_range(). MIGRARTE_HIGHATOMIC should not merge with other

RE: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

Kevin, On Sat, Dec 11 2021 at 07:44, Kevin Tian wrote: >> From: Thomas Gleixner >> On Fri, Dec 10 2021 at 08:39, Jason Gunthorpe wrote: >> > It is clever, we don't have an vIOMMU that supplies vIR today, so by >> > definition all guests are excluded and only bare metal works. >> >> Dammit. Now

Re: [patch V3 03/35] x86/apic/msi: Use PCI device MSI property

On Fri, Dec 10, 2021 at 11:18:47PM +0100, Thomas Gleixner wrote: > From: Thomas Gleixner > > instead of fiddling with MSI descriptors. > > Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman ___ iommu mailing list

RE: [PATCH 1/4] ioasid: Reserve a global PASID for in-kernel DMA

> From: Jacob Pan > Sent: Saturday, December 11, 2021 2:06 AM > > Hi Jason, > > On Fri, 10 Dec 2021 08:31:09 -0400, Jason Gunthorpe > wrote: > > > On Fri, Dec 10, 2021 at 09:06:24AM +, Jean-Philippe Brucker wrote: > > > On Thu, Dec 09, 2021 at 10:14:04AM -0800, Jacob Pan wrote: > > > > >

RE: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

> From: Thomas Gleixner > Sent: Friday, December 10, 2021 8:13 PM > > >> 5) It's not possible for the kernel to reliably detect whether it is > >> running on bare metal or not. Yes we talked about heuristics, but > >> that's something I really want to avoid. > > > > How would the