Re: 5.10 LTS Kernel: 2 or 6 years?

Hi Greg, On 26.01.2021 [08:29:25 +0100], Greg Kroah-Hartman wrote: > On Mon, Jan 25, 2021 at 11:55:11AM -0800, Scott Branden wrote: > > Hi All, > > > > The 5.10 LTS kernel being officially LTS supported for 2 years > > presents a problem: why would anyone select a 5.10 kernel with 2 > > year LTS

Re: [RFC 00/60] Coscheduling for Linux

On 17.09.2018 [13:33:15 +0200], Peter Zijlstra wrote: > On Fri, Sep 14, 2018 at 06:25:44PM +0200, Jan H. Schönherr wrote: > > On 09/14/2018 01:12 PM, Peter Zijlstra wrote: > > > On Fri, Sep 07, 2018 at 11:39:47PM +0200, Jan H. Schönherr wrote: > > > >> B) Why would I want this? > > > > > >>

Re: [RFC 00/60] Coscheduling for Linux

On 17.09.2018 [13:33:15 +0200], Peter Zijlstra wrote: > On Fri, Sep 14, 2018 at 06:25:44PM +0200, Jan H. Schönherr wrote: > > On 09/14/2018 01:12 PM, Peter Zijlstra wrote: > > > On Fri, Sep 07, 2018 at 11:39:47PM +0200, Jan H. Schönherr wrote: > > > >> B) Why would I want this? > > > > > >>

Re: Kernel panic when enabling cgroup2 io controller at runtime

On 01.11.2018 [12:03:40 -0700], Nishanth Aravamudan wrote: > Hi, > > tl;dr: I see a kernel NULL pointer dereference with Linus' master > (7c6c54b5) when enabling the IO cgroup2 controller at runtime. Is this > PEBKAC and if so what config option am I missing? Actually, this m

Re: Kernel panic when enabling cgroup2 io controller at runtime

On 01.11.2018 [12:03:40 -0700], Nishanth Aravamudan wrote: > Hi, > > tl;dr: I see a kernel NULL pointer dereference with Linus' master > (7c6c54b5) when enabling the IO cgroup2 controller at runtime. Is this > PEBKAC and if so what config option am I missing? Actually, this m

Re: [RFC 61/60] cosched: Accumulated fixes and improvements

On 26.09.2018 [10:25:19 -0700], Nishanth Aravamudan wrote: > On 13.09.2018 [21:19:38 +0200], Jan H. Schönherr wrote: > > Here is an "extra" patch containing bug fixes and warning removals, > > that I have accumulated up to this point. > > > > It goes

Re: [RFC 61/60] cosched: Accumulated fixes and improvements

On 26.09.2018 [10:25:19 -0700], Nishanth Aravamudan wrote: > On 13.09.2018 [21:19:38 +0200], Jan H. Schönherr wrote: > > Here is an "extra" patch containing bug fixes and warning removals, > > that I have accumulated up to this point. > > > > It goes

Re: [RFC 61/60] cosched: Accumulated fixes and improvements

On 13.09.2018 [21:19:38 +0200], Jan H. Schönherr wrote: > Here is an "extra" patch containing bug fixes and warning removals, > that I have accumulated up to this point. > > It goes on top of the other 60 patches. (When it is time for v2, > these fixes will be integrated into the appropriate

Re: [RFC 61/60] cosched: Accumulated fixes and improvements

On 13.09.2018 [21:19:38 +0200], Jan H. Schönherr wrote: > Here is an "extra" patch containing bug fixes and warning removals, > that I have accumulated up to this point. > > It goes on top of the other 60 patches. (When it is time for v2, > these fixes will be integrated into the appropriate

Re: [RFC 00/60] Coscheduling for Linux

On 13.09.2018 [13:31:36 +0200], Jan H. Schönherr wrote: > On 09/13/2018 01:15 AM, Nishanth Aravamudan wrote: > > [...] if I just try to set machine's > > cpu.scheduled to 1, with no other changes (not even changing any child > > cgroup's cpu.scheduled yet), I ge

Re: [RFC 00/60] Coscheduling for Linux

On 13.09.2018 [13:31:36 +0200], Jan H. Schönherr wrote: > On 09/13/2018 01:15 AM, Nishanth Aravamudan wrote: > > [...] if I just try to set machine's > > cpu.scheduled to 1, with no other changes (not even changing any child > > cgroup's cpu.scheduled yet), I ge

Re: [RFC 00/60] Coscheduling for Linux

On 13.09.2018 [01:18:14 +0200], Jan H. Schönherr wrote: > On 09/12/2018 09:34 PM, Jan H. Schönherr wrote: > > That said, I see a hang, too. It seems to happen, when there is a > > cpu.scheduled!=0 group that is not a direct child of the root task group. > > You seem to have

Re: [RFC 00/60] Coscheduling for Linux

On 13.09.2018 [01:18:14 +0200], Jan H. Schönherr wrote: > On 09/12/2018 09:34 PM, Jan H. Schönherr wrote: > > That said, I see a hang, too. It seems to happen, when there is a > > cpu.scheduled!=0 group that is not a direct child of the root task group. > > You seem to have

Re: [RFC 00/60] Coscheduling for Linux

On 12.09.2018 [21:34:14 +0200], Jan H. Schönherr wrote: > On 09/12/2018 02:24 AM, Nishanth Aravamudan wrote: > > [ I am not subscribed to LKML, please keep me CC'd on replies ] > > > > I tried a simple test with several VMs (in my initial test, I have 48 > > idle 1-cpu

Re: [RFC 00/60] Coscheduling for Linux

On 12.09.2018 [21:34:14 +0200], Jan H. Schönherr wrote: > On 09/12/2018 02:24 AM, Nishanth Aravamudan wrote: > > [ I am not subscribed to LKML, please keep me CC'd on replies ] > > > > I tried a simple test with several VMs (in my initial test, I have 48 > > idle 1-cpu

Re: [RFC 00/60] Coscheduling for Linux

[ I am not subscribed to LKML, please keep me CC'd on replies ] On 07.09.2018 [23:39:47 +0200], Jan H. Schönherr wrote: > This patch series extends CFS with support for coscheduling. The > implementation is versatile enough to cover many different > coscheduling use-cases, while at the same time

Re: [RFC 00/60] Coscheduling for Linux

[ I am not subscribed to LKML, please keep me CC'd on replies ] On 07.09.2018 [23:39:47 +0200], Jan H. Schönherr wrote: > This patch series extends CFS with support for coscheduling. The > implementation is versatile enough to cover many different > coscheduling use-cases, while at the same time

Re: [PATCH 1/1 v4] drivers/nvme: default to 4k device page size

On 05.11.2015 [11:58:39 -0800], Christoph Hellwig wrote: > Looks fine, > > Reviewed-by: Christoph Hellwig > > ... but I doubt we'll ever bother updating it. Most architectures > with arger page sizes also have iommus and would need different settings > for different iommus vs direct mapping

Re: [PATCH 1/1 v4] drivers/nvme: default to 4k device page size

On 05.11.2015 [11:58:39 -0800], Christoph Hellwig wrote: > Looks fine, > > Reviewed-by: Christoph Hellwig > > ... but I doubt we'll ever bother updating it. Most architectures > with arger page sizes also have iommus and would need different settings > for different iommus vs

Re: [PATCH 1/1 v4] drivers/nvme: default to 4k device page size

On 05.11.2015 [11:58:39 -0800], Christoph Hellwig wrote: > Looks fine, > > Reviewed-by: Christoph Hellwig > > ... but I doubt we'll ever bother updating it. Most architectures > with arger page sizes also have iommus and would need different settings > for different iommus vs direct mapping

[PATCH 1/1 v4] drivers/nvme: default to 4k device page size

On 03.11.2015 [13:46:25 +], Keith Busch wrote: > On Tue, Nov 03, 2015 at 05:18:24AM -0800, Christoph Hellwig wrote: > > On Fri, Oct 30, 2015 at 02:35:11PM -0700, Nishanth Aravamudan wrote: > > > diff --git a/drivers/block/nvme-core.c b/drivers/block/nvme-core.c > &

[PATCH 1/1 v4] drivers/nvme: default to 4k device page size

On 03.11.2015 [13:46:25 +], Keith Busch wrote: > On Tue, Nov 03, 2015 at 05:18:24AM -0800, Christoph Hellwig wrote: > > On Fri, Oct 30, 2015 at 02:35:11PM -0700, Nishanth Aravamudan wrote: > > > diff --git a/drivers/block/nvme-core.c b/drivers/block/nvme-core.c > &

Re: [PATCH 1/1 v4] drivers/nvme: default to 4k device page size

On 05.11.2015 [11:58:39 -0800], Christoph Hellwig wrote: > Looks fine, > > Reviewed-by: Christoph Hellwig > > ... but I doubt we'll ever bother updating it. Most architectures > with arger page sizes also have iommus and would need different settings > for different iommus vs

Re: [PATCH 1/1 v3] drivers/nvme: default to 4k device page size

On 30.10.2015 [21:48:48 +], Keith Busch wrote: > On Fri, Oct 30, 2015 at 02:35:11PM -0700, Nishanth Aravamudan wrote: > > Given that it's 4K just about everywhere by default (and sort of > > implicitly expected to be, I guess), I think I'd prefer we default to > > 4K.

Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

On 29.10.2015 [18:49:55 -0700], David Miller wrote: > From: Nishanth Aravamudan > Date: Thu, 29 Oct 2015 08:57:01 -0700 > > > So, would that imply changing just the NVMe driver code rather than > > adding the dma_page_shift API at all? What about > > architectures

[PATCH 1/1 v3] drivers/nvme: default to 4k device page size

On 29.10.2015 [17:20:43 +], Busch, Keith wrote: > On Thu, Oct 29, 2015 at 08:57:01AM -0700, Nishanth Aravamudan wrote: > > On 29.10.2015 [04:55:36 -0700], Christoph Hellwig wrote: > > > We had a quick cht about this issue and I think we simply should > > > default to

[PATCH 1/1 v3] drivers/nvme: default to 4k device page size

On 29.10.2015 [17:20:43 +], Busch, Keith wrote: > On Thu, Oct 29, 2015 at 08:57:01AM -0700, Nishanth Aravamudan wrote: > > On 29.10.2015 [04:55:36 -0700], Christoph Hellwig wrote: > > > We had a quick cht about this issue and I think we simply should > > > default to

Re: [PATCH 1/1 v3] drivers/nvme: default to 4k device page size

On 30.10.2015 [21:48:48 +], Keith Busch wrote: > On Fri, Oct 30, 2015 at 02:35:11PM -0700, Nishanth Aravamudan wrote: > > Given that it's 4K just about everywhere by default (and sort of > > implicitly expected to be, I guess), I think I'd prefer we default to > > 4K.

Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

On 29.10.2015 [18:49:55 -0700], David Miller wrote: > From: Nishanth Aravamudan <n...@linux.vnet.ibm.com> > Date: Thu, 29 Oct 2015 08:57:01 -0700 > > > So, would that imply changing just the NVMe driver code rather than > > adding the dma_page_shift API at all? W

Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

On 29.10.2015 [04:55:36 -0700], Christoph Hellwig wrote: > On Wed, Oct 28, 2015 at 01:59:23PM +, Busch, Keith wrote: > > The "new" interface for all the other architectures is the same as the > > old one we've been using for the last 5 years. > > > > I welcome x86 maintainer feedback to

Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

On 29.10.2015 [04:55:36 -0700], Christoph Hellwig wrote: > On Wed, Oct 28, 2015 at 01:59:23PM +, Busch, Keith wrote: > > The "new" interface for all the other architectures is the same as the > > old one we've been using for the last 5 years. > > > > I welcome x86 maintainer feedback to

Re: [PATCH 2/7 v2] powerpc/dma-mapping: override dma_get_page_shift

On 28.10.2015 [11:20:05 +0900], Benjamin Herrenschmidt wrote: > On Tue, 2015-10-27 at 18:54 -0700, Nishanth Aravamudan wrote: > > > > In "bypass" mode, what TCE size is used? Is it guaranteed to be 4K? > > None :-) The TCEs are completely bypassed. You get a N:M

Re: [PATCH 2/7 v2] powerpc/dma-mapping: override dma_get_page_shift

On 28.10.2015 [12:00:20 +1100], Alexey Kardashevskiy wrote: > On 10/28/2015 09:27 AM, Nishanth Aravamudan wrote: > >On 27.10.2015 [17:02:16 +1100], Alexey Kardashevskiy wrote: > >>On 10/24/2015 07:57 AM, Nishanth Aravamudan wrote: > >>>On Power, the kernel's page si

Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

On 27.10.2015 [17:53:22 -0700], David Miller wrote: > From: Nishanth Aravamudan > Date: Tue, 27 Oct 2015 15:20:10 -0700 > > > Well, looks like I should spin up a v4 anyways for the powerpc changes. > > So, to make sure I understand your point, should I make the generic &

Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

On 28.10.2015 [09:57:48 +1100], Julian Calaby wrote: > Hi Nishanth, > > On Wed, Oct 28, 2015 at 9:20 AM, Nishanth Aravamudan > wrote: > > On 26.10.2015 [18:27:46 -0700], David Miller wrote: > >> From: Nishanth Aravamudan > >> Date: Fri, 23 Oct 2015 13:54:2

Re: [PATCH 2/7 v2] powerpc/dma-mapping: override dma_get_page_shift

On 27.10.2015 [17:02:16 +1100], Alexey Kardashevskiy wrote: > On 10/24/2015 07:57 AM, Nishanth Aravamudan wrote: > >On Power, the kernel's page size can differ from the IOMMU's page size, > >so we need to override the generic implementation, which always returns > >the kerne

Re: [PATCH 4/7 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

On 27.10.2015 [16:56:10 +1100], Alexey Kardashevskiy wrote: > On 10/24/2015 07:59 AM, Nishanth Aravamudan wrote: > >When DDW (Dynamic DMA Windows) are present for a device, we have stored > >the TCE (Translation Control Entry) size in a special device tree > >property. Check i

Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

On 26.10.2015 [18:27:46 -0700], David Miller wrote: > From: Nishanth Aravamudan > Date: Fri, 23 Oct 2015 13:54:20 -0700 > > > 1) add a generic dma_get_page_shift implementation that just returns > > PAGE_SHIFT > > I won't object to this patch series, but if I had impl

Re: [PATCH 4/7 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

On 27.10.2015 [16:56:10 +1100], Alexey Kardashevskiy wrote: > On 10/24/2015 07:59 AM, Nishanth Aravamudan wrote: > >When DDW (Dynamic DMA Windows) are present for a device, we have stored > >the TCE (Translation Control Entry) size in a special device tree > >property. Check i

Re: [PATCH 2/7 v2] powerpc/dma-mapping: override dma_get_page_shift

On 27.10.2015 [17:02:16 +1100], Alexey Kardashevskiy wrote: > On 10/24/2015 07:57 AM, Nishanth Aravamudan wrote: > >On Power, the kernel's page size can differ from the IOMMU's page size, > >so we need to override the generic implementation, which always returns > >the kerne

Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

On 26.10.2015 [18:27:46 -0700], David Miller wrote: > From: Nishanth Aravamudan <n...@linux.vnet.ibm.com> > Date: Fri, 23 Oct 2015 13:54:20 -0700 > > > 1) add a generic dma_get_page_shift implementation that just returns > > PAGE_SHIFT > > I won't object t

Re: [PATCH 2/7 v2] powerpc/dma-mapping: override dma_get_page_shift

On 28.10.2015 [12:00:20 +1100], Alexey Kardashevskiy wrote: > On 10/28/2015 09:27 AM, Nishanth Aravamudan wrote: > >On 27.10.2015 [17:02:16 +1100], Alexey Kardashevskiy wrote: > >>On 10/24/2015 07:57 AM, Nishanth Aravamudan wrote: > >>>On Power, the kernel's page si

Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

On 27.10.2015 [17:53:22 -0700], David Miller wrote: > From: Nishanth Aravamudan <n...@linux.vnet.ibm.com> > Date: Tue, 27 Oct 2015 15:20:10 -0700 > > > Well, looks like I should spin up a v4 anyways for the powerpc changes. > > So, to make sure I understand your point

Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

On 28.10.2015 [09:57:48 +1100], Julian Calaby wrote: > Hi Nishanth, > > On Wed, Oct 28, 2015 at 9:20 AM, Nishanth Aravamudan > <n...@linux.vnet.ibm.com> wrote: > > On 26.10.2015 [18:27:46 -0700], David Miller wrote: > >> From: Nishanth Aravamudan <n...@linux.

Re: [PATCH 2/7 v2] powerpc/dma-mapping: override dma_get_page_shift

On 28.10.2015 [11:20:05 +0900], Benjamin Herrenschmidt wrote: > On Tue, 2015-10-27 at 18:54 -0700, Nishanth Aravamudan wrote: > > > > In "bypass" mode, what TCE size is used? Is it guaranteed to be 4K? > > None :-) The TCEs are completely bypassed. You get a N:M

Re: [PATCH 5/7] [RFC PATCH 5/7] sparc: rename kernel/iommu_common.h -> include/asm/iommu_common.h

[Apologies for the subject line, should just have the [RFC PATCH 5/7]] On 23.10.2015 [14:00:08 -0700], Nishanth Aravamudan wrote: > In order to cleanly expose the desired IOMMU page shift via the new > dma_get_page_shift API, we need to have the sparc constants available in > a mor

[PATCH 7/7 v2] drivers/nvme: default to the IOMMU page size

page size, rather than the kernel's page size. With this patch, a NVMe device survives our internal hardware exerciser; the kernel BUGs within a few seconds without the patch. Signed-off-by: Nishanth Aravamudan --- v1 -> v2: Based upon feedback from Christoph Hellwig, implement the IOMMU p

[RFC PATCH 6/7] sparc/dma-mapping: override dma_get_page_shift

On sparc, the kernel's page size differs from the IOMMU's page size, so override the generic implementation, which always returns the kernel's page size, and return IOMMU_PAGE_SHIFT instead. Signed-off-by: Nishanth Aravamudan --- I know very little about sparc, so please correct me

[PATCH 5/7] [RFC PATCH 5/7] sparc: rename kernel/iommu_common.h -> include/asm/iommu_common.h

In order to cleanly expose the desired IOMMU page shift via the new dma_get_page_shift API, we need to have the sparc constants available in a more typical location. There should be no functional impact to this move, but it is untested. Signed-off-by: Nishanth Aravamudan --- arch/sparc/include

[PATCH 4/7 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

the value up in struct iommu_table. If we don't find a iommu_table, fallback to the kernel's page size. Signed-off-by: Nishanth Aravamudan --- arch/powerpc/platforms/pseries/iommu.c | 36 ++ 1 file changed, 36 insertions(+) diff --git a/arch/powerpc/platforms

[PATCH 3/7 v2] powerpc/dma: implement per-platform dma_get_page_shift

. DDW is a pseries-specific feature, so allow platforms to override the implementation of dma_get_page_shift if desired. Signed-off-by: Nishanth Aravamudan --- arch/powerpc/include/asm/machdep.h | 3 ++- arch/powerpc/kernel/dma.c | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) diff

Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

[Sorry, subject should have been 0/7!] On 23.10.2015 [13:54:20 -0700], Nishanth Aravamudan wrote: > We received a bug report recently when DDW (64-bit direct DMA on Power) > is not enabled for NVMe devices. In that case, we fall back to 32-bit > DMA via the IOMMU, which is always done vi

[PATCH 2/7 v2] powerpc/dma-mapping: override dma_get_page_shift

-by: Nishanth Aravamudan --- arch/powerpc/include/asm/dma-mapping.h | 3 +++ arch/powerpc/kernel/dma.c | 9 + 2 files changed, 12 insertions(+) diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h index 7f522c0..c5638f4 100644 --- a/arch

[PATCH 1/7 v3] dma-mapping: add generic dma_get_page_shift API

Drivers like NVMe need to be able to determine the page size used for DMA transfers. Add a new API that defaults to return PAGE_SHIFT on all architectures. Signed-off-by: Nishanth Aravamudan --- v1 -> v2: Based upon feedback from Christoph Hellwig, implement the IOMMU page size loo

[PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

We received a bug report recently when DDW (64-bit direct DMA on Power) is not enabled for NVMe devices. In that case, we fall back to 32-bit DMA via the IOMMU, which is always done via 4K TCEs (Translation Control Entries). The NVMe device driver, though, assumes that the DMA alignment for the

[PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

We received a bug report recently when DDW (64-bit direct DMA on Power) is not enabled for NVMe devices. In that case, we fall back to 32-bit DMA via the IOMMU, which is always done via 4K TCEs (Translation Control Entries). The NVMe device driver, though, assumes that the DMA alignment for the

[PATCH 5/7] [RFC PATCH 5/7] sparc: rename kernel/iommu_common.h -> include/asm/iommu_common.h

In order to cleanly expose the desired IOMMU page shift via the new dma_get_page_shift API, we need to have the sparc constants available in a more typical location. There should be no functional impact to this move, but it is untested. Signed-off-by: Nishanth Aravamudan <n...@linux.vnet.ibm.

[RFC PATCH 6/7] sparc/dma-mapping: override dma_get_page_shift

On sparc, the kernel's page size differs from the IOMMU's page size, so override the generic implementation, which always returns the kernel's page size, and return IOMMU_PAGE_SHIFT instead. Signed-off-by: Nishanth Aravamudan <n...@linux.vnet.ibm.com> --- I know very little about spa

[PATCH 1/7 v3] dma-mapping: add generic dma_get_page_shift API

Drivers like NVMe need to be able to determine the page size used for DMA transfers. Add a new API that defaults to return PAGE_SHIFT on all architectures. Signed-off-by: Nishanth Aravamudan <n...@linux.vnet.ibm.com> --- v1 -> v2: Based upon feedback from Christoph Hellwig, implement

Re: [PATCH 5/7] [RFC PATCH 5/7] sparc: rename kernel/iommu_common.h -> include/asm/iommu_common.h

[Apologies for the subject line, should just have the [RFC PATCH 5/7]] On 23.10.2015 [14:00:08 -0700], Nishanth Aravamudan wrote: > In order to cleanly expose the desired IOMMU page shift via the new > dma_get_page_shift API, we need to have the sparc constants available in > a mor

[PATCH 7/7 v2] drivers/nvme: default to the IOMMU page size

page size, rather than the kernel's page size. With this patch, a NVMe device survives our internal hardware exerciser; the kernel BUGs within a few seconds without the patch. Signed-off-by: Nishanth Aravamudan <n...@linux.vnet.ibm.com> --- v1 -> v2: Based upon feedback from Christop

[PATCH 2/7 v2] powerpc/dma-mapping: override dma_get_page_shift

-by: Nishanth Aravamudan <n...@linux.vnet.ibm.com> --- arch/powerpc/include/asm/dma-mapping.h | 3 +++ arch/powerpc/kernel/dma.c | 9 + 2 files changed, 12 insertions(+) diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h index 7

Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

[Sorry, subject should have been 0/7!] On 23.10.2015 [13:54:20 -0700], Nishanth Aravamudan wrote: > We received a bug report recently when DDW (64-bit direct DMA on Power) > is not enabled for NVMe devices. In that case, we fall back to 32-bit > DMA via the IOMMU, which is always done vi

[PATCH 4/7 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

the value up in struct iommu_table. If we don't find a iommu_table, fallback to the kernel's page size. Signed-off-by: Nishanth Aravamudan <n...@linux.vnet.ibm.com> --- arch/powerpc/platforms/pseries/iommu.c | 36 ++ 1 file changed, 36 insertions(+) diff

[PATCH 3/7 v2] powerpc/dma: implement per-platform dma_get_page_shift

. DDW is a pseries-specific feature, so allow platforms to override the implementation of dma_get_page_shift if desired. Signed-off-by: Nishanth Aravamudan <n...@linux.vnet.ibm.com> --- arch/powerpc/include/asm/machdep.h | 3 ++- arch/powerpc/kernel/dma.c | 2 ++ 2 files changed, 4 inse

Re: [PATCH 1/5 v2] dma-mapping: add generic dma_get_page_shift API

On 15.10.2015 [15:52:19 -0700], Nishanth Aravamudan wrote: > On 14.10.2015 [08:42:51 -0700], Christoph Hellwig wrote: > > Hi Nishanth, > > > > sorry for the late reply. > > > > > > On Power, since it's technically variable, we'd need a function. S

Re: [PATCH 1/5 v2] dma-mapping: add generic dma_get_page_shift API

On 15.10.2015 [15:52:19 -0700], Nishanth Aravamudan wrote: > On 14.10.2015 [08:42:51 -0700], Christoph Hellwig wrote: > > Hi Nishanth, > > > > sorry for the late reply. > > > > > > On Power, since it's technically variable, we'd need a function. S

Re: [PATCH 1/5 v2] dma-mapping: add generic dma_get_page_shift API

On 14.10.2015 [08:42:51 -0700], Christoph Hellwig wrote: > Hi Nishanth, > > sorry for the late reply. > > > > On Power, since it's technically variable, we'd need a function. So are > > > you suggesting define'ing it to a function just on Power and leaving it > > > a constant elsewhere? > > > >

Re: [PATCH 1/5 v2] dma-mapping: add generic dma_get_page_shift API

On 14.10.2015 [08:42:51 -0700], Christoph Hellwig wrote: > Hi Nishanth, > > sorry for the late reply. > > > > On Power, since it's technically variable, we'd need a function. So are > > > you suggesting define'ing it to a function just on Power and leaving it > > > a constant elsewhere? > > > >

Re: [PATCH 1/5 v2] dma-mapping: add generic dma_get_page_shift API

Hi Christoph, On 12.10.2015 [14:06:51 -0700], Nishanth Aravamudan wrote: > On 06.10.2015 [02:51:36 -0700], Christoph Hellwig wrote: > > Do we need a function here or can we just have a IOMMU_PAGE_SHIFT define > > with an #ifndef in common code? > > On Power, since it's techn

Re: [PATCH 1/5 v2] dma-mapping: add generic dma_get_page_shift API

Hi Christoph, On 12.10.2015 [14:06:51 -0700], Nishanth Aravamudan wrote: > On 06.10.2015 [02:51:36 -0700], Christoph Hellwig wrote: > > Do we need a function here or can we just have a IOMMU_PAGE_SHIFT define > > with an #ifndef in common code? > > On Power, since it's techn

Re: [PATCH 1/2] powerpc/iommu: expose IOMMU page shift

On 12.10.2015 [09:03:52 -0700], Nishanth Aravamudan wrote: > On 06.10.2015 [14:19:43 +1100], David Gibson wrote: > > On Fri, Oct 02, 2015 at 10:18:00AM -0700, Nishanth Aravamudan wrote: > > > We will leverage this macro in the NVMe driver, which needs to know the > > >

Re: [PATCH 1/5 v2] dma-mapping: add generic dma_get_page_shift API

On 06.10.2015 [02:51:36 -0700], Christoph Hellwig wrote: > Do we need a function here or can we just have a IOMMU_PAGE_SHIFT define > with an #ifndef in common code? On Power, since it's technically variable, we'd need a function. So are you suggesting define'ing it to a function just on Power

Re: [PATCH 1/5 v2] dma-mapping: add generic dma_get_page_shift API

On 06.10.2015 [02:51:36 -0700], Christoph Hellwig wrote: > Do we need a function here or can we just have a IOMMU_PAGE_SHIFT define > with an #ifndef in common code? I suppose we could do that -- I wasn't sure if the macro would be palatable. > Also not all architectures use dma-mapping-common.h

Re: [PATCH 1/2] powerpc/iommu: expose IOMMU page shift

On 06.10.2015 [14:19:43 +1100], David Gibson wrote: > On Fri, Oct 02, 2015 at 10:18:00AM -0700, Nishanth Aravamudan wrote: > > We will leverage this macro in the NVMe driver, which needs to know the > > configured IOMMU page shift to properly configure its device's page > >

Re: [PATCH 1/5 v2] dma-mapping: add generic dma_get_page_shift API

On 06.10.2015 [02:51:36 -0700], Christoph Hellwig wrote: > Do we need a function here or can we just have a IOMMU_PAGE_SHIFT define > with an #ifndef in common code? I suppose we could do that -- I wasn't sure if the macro would be palatable. > Also not all architectures use dma-mapping-common.h

Re: [PATCH 1/2] powerpc/iommu: expose IOMMU page shift

On 06.10.2015 [14:19:43 +1100], David Gibson wrote: > On Fri, Oct 02, 2015 at 10:18:00AM -0700, Nishanth Aravamudan wrote: > > We will leverage this macro in the NVMe driver, which needs to know the > > configured IOMMU page shift to properly configure its device's page > >

Re: [PATCH 1/5 v2] dma-mapping: add generic dma_get_page_shift API

On 06.10.2015 [02:51:36 -0700], Christoph Hellwig wrote: > Do we need a function here or can we just have a IOMMU_PAGE_SHIFT define > with an #ifndef in common code? On Power, since it's technically variable, we'd need a function. So are you suggesting define'ing it to a function just on Power

Re: [PATCH 1/2] powerpc/iommu: expose IOMMU page shift

On 12.10.2015 [09:03:52 -0700], Nishanth Aravamudan wrote: > On 06.10.2015 [14:19:43 +1100], David Gibson wrote: > > On Fri, Oct 02, 2015 at 10:18:00AM -0700, Nishanth Aravamudan wrote: > > > We will leverage this macro in the NVMe driver, which needs to know the > > >

Re: [PATCH 0/5 v2] Fix NVMe driver support on Power with 32-bit DMA

On 03.10.2015 [07:35:09 +1000], Benjamin Herrenschmidt wrote: > On Fri, 2015-10-02 at 14:04 -0700, Nishanth Aravamudan wrote: > > Right, I did start with your advice and tried that approach, but it > > turned out I was wrong about the actual issue at the time. The problem >

Re: [PATCH 0/5 v2] Fix NVMe driver support on Power with 32-bit DMA

On 03.10.2015 [06:51:06 +1000], Benjamin Herrenschmidt wrote: > On Fri, 2015-10-02 at 13:09 -0700, Nishanth Aravamudan wrote: > > > 1) add a generic dma_get_page_shift implementation that just returns > > PAGE_SHIFT > > So you chose to return the granularity of the iomm

[PATCH 5/5 v2] drivers/nvme: default to the IOMMU page size

We received a bug report recently when DDW (64-bit direct DMA on Power) is not enabled for NVMe devices. In that case, we fall back to 32-bit DMA via the IOMMU, which is always done via 4K TCEs (Translation Control Entries). The NVMe device driver, though, assumes that the DMA alignment for the

[PATCH 4/5 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

the value up in struct iommu_table. If we don't find a iommu_table, fallback to the kernel's page size. Signed-off-by: Nishanth Aravamudan diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c index 0946b98..1bf6471 100644 --- a/arch/powerpc/platforms

[PATCH 3/5 v2] powerpc/dma: implement per-platform dma_get_page_shift

. DDW is a pseries-specific feature, so allow platforms to override the implementation of dma_get_page_shift if desired. Signed-off-by: Nishanth Aravamudan diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h index cab6753..5c372e3 100644 --- a/arch/powerpc/include

[PATCH 2/5 v2] powerpc/dma-mapping: override dma_get_page_shift

-by: Nishanth Aravamudan diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h index 7f522c0..c5638f4 100644 --- a/arch/powerpc/include/asm/dma-mapping.h +++ b/arch/powerpc/include/asm/dma-mapping.h @@ -125,6 +125,9 @@ static inline void set_dma_offset(struct

[PATCH 1/5 v2] dma-mapping: add generic dma_get_page_shift API

Drivers like NVMe need to be able to determine the page size used for DMA transfers. Add a new API that defaults to return PAGE_SHIFT on all architectures. Signed-off-by: Nishanth Aravamudan diff --git a/include/asm-generic/dma-mapping-common.h b/include/asm-generic/dma-mapping-common.h index

[PATCH 0/5 v2] Fix NVMe driver support on Power with 32-bit DMA

We received a bug report recently when DDW (64-bit direct DMA on Power) is not enabled for NVMe devices. In that case, we fall back to 32-bit DMA via the IOMMU, which is always done via 4K TCEs (Translation Control Entries). The NVMe device driver, though, assumes that the DMA alignment for the

Re: [PATCH 2/2] drivers/nvme: default to the IOMMU page size on Power

On 02.10.2015 [10:25:44 -0700], Christoph Hellwig wrote: > Hi Nishanth, > > please expose this value through the generic DMA API instead of adding > architecture specific hacks to drivers. Ok, I'm happy to do that instead -- what I struggled with is that I don't have enough knowledge of the

[PATCH 2/2] drivers/nvme: default to the IOMMU page size on Power

exerciser; the kernel BUGs within a few seconds without the patch. Signed-off-by: Nishanth Aravamudan diff --git a/drivers/block/nvme-core.c b/drivers/block/nvme-core.c index 7920c27..969a95e 100644 --- a/drivers/block/nvme-core.c +++ b/drivers/block/nvme-core.c @@ -42,6 +42,7 @@ #include

[PATCH 0/2] Fix NVMe driver support on Power with 32-bit DMA

We received a bug report recently when DDW (64-bit direct DMA on Power) is not enabled for NVMe devices. In that case, we fall back to 32-bit DMA via the IOMMU, which is always done via 4K TCEs (Translation Control Entries). The NVMe device driver, though, assumes that the DMA alignment for the

[PATCH 1/2] powerpc/iommu: expose IOMMU page shift

We will leverage this macro in the NVMe driver, which needs to know the configured IOMMU page shift to properly configure its device's page size. Signed-off-by: Nishanth Aravamudan --- Given this is available, it seems reasonable to expose -- and it doesn't really make sense to make the driver

[PATCH 0/2] Fix NVMe driver support on Power with 32-bit DMA

We received a bug report recently when DDW (64-bit direct DMA on Power) is not enabled for NVMe devices. In that case, we fall back to 32-bit DMA via the IOMMU, which is always done via 4K TCEs (Translation Control Entries). The NVMe device driver, though, assumes that the DMA alignment for the

[PATCH 1/2] powerpc/iommu: expose IOMMU page shift

We will leverage this macro in the NVMe driver, which needs to know the configured IOMMU page shift to properly configure its device's page size. Signed-off-by: Nishanth Aravamudan <n...@linux.vnet.ibm.com> --- Given this is available, it seems reasonable to expose -- and it doesn't reall

[PATCH 2/2] drivers/nvme: default to the IOMMU page size on Power

exerciser; the kernel BUGs within a few seconds without the patch. Signed-off-by: Nishanth Aravamudan <n...@linux.vnet.ibm.com> diff --git a/drivers/block/nvme-core.c b/drivers/block/nvme-core.c index 7920c27..969a95e 100644 --- a/drivers/block/nvme-core.c +++ b/drivers/block/nvme-core.c @@

Re: [PATCH 2/2] drivers/nvme: default to the IOMMU page size on Power

On 02.10.2015 [10:25:44 -0700], Christoph Hellwig wrote: > Hi Nishanth, > > please expose this value through the generic DMA API instead of adding > architecture specific hacks to drivers. Ok, I'm happy to do that instead -- what I struggled with is that I don't have enough knowledge of the

[PATCH 3/5 v2] powerpc/dma: implement per-platform dma_get_page_shift

. DDW is a pseries-specific feature, so allow platforms to override the implementation of dma_get_page_shift if desired. Signed-off-by: Nishanth Aravamudan <n...@linux.vnet.ibm.com> diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h index cab6753..5c372e3

[PATCH 0/5 v2] Fix NVMe driver support on Power with 32-bit DMA

We received a bug report recently when DDW (64-bit direct DMA on Power) is not enabled for NVMe devices. In that case, we fall back to 32-bit DMA via the IOMMU, which is always done via 4K TCEs (Translation Control Entries). The NVMe device driver, though, assumes that the DMA alignment for the

[PATCH 1/5 v2] dma-mapping: add generic dma_get_page_shift API

Drivers like NVMe need to be able to determine the page size used for DMA transfers. Add a new API that defaults to return PAGE_SHIFT on all architectures. Signed-off-by: Nishanth Aravamudan <n...@linux.vnet.ibm.com> diff --git a/include/asm-generic/dma-mapping-common.h b/include/asm-g

[PATCH 4/5 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

the value up in struct iommu_table. If we don't find a iommu_table, fallback to the kernel's page size. Signed-off-by: Nishanth Aravamudan <n...@linux.vnet.ibm.com> diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c index 0946b98..1bf6471

[PATCH 5/5 v2] drivers/nvme: default to the IOMMU page size

We received a bug report recently when DDW (64-bit direct DMA on Power) is not enabled for NVMe devices. In that case, we fall back to 32-bit DMA via the IOMMU, which is always done via 4K TCEs (Translation Control Entries). The NVMe device driver, though, assumes that the DMA alignment for the

  1   2   3   4   5   6   >