All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Ramon Fried <ramon.fried@gmail.com>, benh@kernel.crashing.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linuxppc-dev@lists.ozlabs.org,
	open list <linux-kernel@vger.kernel.org>,
	iommu@lists.linux-foundation.org, hch@lst.de, linux@roeck-us.net
Subject: Re: [PATCH 5/5] dma-direct: always allow dma mask <= physiscal memory size
Date: Mon, 19 Nov 2018 15:50:35 +0000	[thread overview]
Message-ID: <bb76b9a1-dc3a-2357-a871-291d68703776@arm.com> (raw)
In-Reply-To: <CA+Kvs9kPtTZavq91NXs-7edVO5Fxp8gPO=FD35i9_izAdGMkKw@mail.gmail.com>

On 19/11/2018 14:18, Ramon Fried wrote:
> On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>>
>> On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote:
>>>> -        * Because 32-bit DMA masks are so common we expect every architecture
>>>> -        * to be able to satisfy them - either by not supporting more physical
>>>> -        * memory, or by providing a ZONE_DMA32.  If neither is the case, the
>>>> -        * architecture needs to use an IOMMU instead of the direct mapping.
>>>> -        */
>>>> -       if (mask < phys_to_dma(dev, DMA_BIT_MASK(32)))
>>>> +       u64 min_mask;
>>>> +
>>>> +       if (IS_ENABLED(CONFIG_ZONE_DMA))
>>>> +               min_mask = DMA_BIT_MASK(ARCH_ZONE_DMA_BITS);
>>>> +       else
>>>> +               min_mask = DMA_BIT_MASK(32);
>>>> +
>>>> +       min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT);
>>>> +
>>>> +       if (mask >= phys_to_dma(dev, min_mask))
>>>>                   return 0;
>>>> -#endif
>>>>           return 1;
>>>>    }
>>>
>>> So I believe I have run into the same issue that Guenter reported. On
>>> an x86_64 system w/ Intel IOMMU. I wasn't able to complete boot and
>>> all probe attempts for various devices were failing with -EIO errors.
>>>
>>> I believe the last mask check should be "if (mask < phys_to_dma(dev,
>>> min_mask))" not a ">=" check.
>>
>> Right, that test is backwards. I needed to change it here too (powermac
>> with the rest of the powerpc series).
>>
>> Cheers,
>> Ben.
>>
>>
> 
> Hi, I'm working on a MIPS64 soc with PCIe root complex on it, and it
> appears that this series of patches are causing all PCI drivers that
> request 64bit mask to fail with -5.
> It's broken in 4.19. However, I just checked, it working on master.
> We may need to backport a couple of patches to 4.19. I'm not sure
> though which patches should be backported as there were at least 10
> patches resolving this dma_direct area recently.
> Christoph, Robin.
> Can we ask Greg to backport all these changes ? What do you think ?

As far as I'm aware, the only real issue in 4.19 was my subtle breakage 
around setting bus_dma_mask - that's fixed by 6778be4e5209, which 
according to my inbox got picked up by autosel for 4.19 stable last week.

Robin.

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Ramon Fried <ramon.fried@gmail.com>, benh@kernel.crashing.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	open list <linux-kernel@vger.kernel.org>,
	iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
	hch@lst.de, linux@roeck-us.net
Subject: Re: [PATCH 5/5] dma-direct: always allow dma mask <= physiscal memory size
Date: Mon, 19 Nov 2018 15:50:35 +0000	[thread overview]
Message-ID: <bb76b9a1-dc3a-2357-a871-291d68703776@arm.com> (raw)
In-Reply-To: <CA+Kvs9kPtTZavq91NXs-7edVO5Fxp8gPO=FD35i9_izAdGMkKw@mail.gmail.com>

On 19/11/2018 14:18, Ramon Fried wrote:
> On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>>
>> On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote:
>>>> -        * Because 32-bit DMA masks are so common we expect every architecture
>>>> -        * to be able to satisfy them - either by not supporting more physical
>>>> -        * memory, or by providing a ZONE_DMA32.  If neither is the case, the
>>>> -        * architecture needs to use an IOMMU instead of the direct mapping.
>>>> -        */
>>>> -       if (mask < phys_to_dma(dev, DMA_BIT_MASK(32)))
>>>> +       u64 min_mask;
>>>> +
>>>> +       if (IS_ENABLED(CONFIG_ZONE_DMA))
>>>> +               min_mask = DMA_BIT_MASK(ARCH_ZONE_DMA_BITS);
>>>> +       else
>>>> +               min_mask = DMA_BIT_MASK(32);
>>>> +
>>>> +       min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT);
>>>> +
>>>> +       if (mask >= phys_to_dma(dev, min_mask))
>>>>                   return 0;
>>>> -#endif
>>>>           return 1;
>>>>    }
>>>
>>> So I believe I have run into the same issue that Guenter reported. On
>>> an x86_64 system w/ Intel IOMMU. I wasn't able to complete boot and
>>> all probe attempts for various devices were failing with -EIO errors.
>>>
>>> I believe the last mask check should be "if (mask < phys_to_dma(dev,
>>> min_mask))" not a ">=" check.
>>
>> Right, that test is backwards. I needed to change it here too (powermac
>> with the rest of the powerpc series).
>>
>> Cheers,
>> Ben.
>>
>>
> 
> Hi, I'm working on a MIPS64 soc with PCIe root complex on it, and it
> appears that this series of patches are causing all PCI drivers that
> request 64bit mask to fail with -5.
> It's broken in 4.19. However, I just checked, it working on master.
> We may need to backport a couple of patches to 4.19. I'm not sure
> though which patches should be backported as there were at least 10
> patches resolving this dma_direct area recently.
> Christoph, Robin.
> Can we ask Greg to backport all these changes ? What do you think ?

As far as I'm aware, the only real issue in 4.19 was my subtle breakage 
around setting bus_dma_mask - that's fixed by 6778be4e5209, which 
according to my inbox got picked up by autosel for 4.19 stable last week.

Robin.

  reply	other threads:[~2018-11-19 15:50 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-27 22:35 dma mask related fixups (including full bus_dma_mask support) v2 Christoph Hellwig
2018-09-27 22:35 ` Christoph Hellwig
2018-09-27 22:35 ` [PATCH 1/5] dma-mapping: make the get_required_mask method available unconditionally Christoph Hellwig
2018-09-27 22:35   ` Christoph Hellwig
2018-09-27 22:35   ` Christoph Hellwig
2018-09-27 22:35 ` [PATCH 2/5] dma-direct: add an explicit dma_direct_get_required_mask Christoph Hellwig
2018-09-27 22:35   ` Christoph Hellwig
2018-09-27 22:35   ` Christoph Hellwig
2018-09-27 22:35 ` [PATCH 3/5] dma-direct: refine dma_direct_alloc zone selection Christoph Hellwig
2018-09-27 22:35   ` Christoph Hellwig
2018-09-27 22:35 ` [PATCH 4/5] dma-direct: implement complete bus_dma_mask handling Christoph Hellwig
2018-09-27 22:35   ` Christoph Hellwig
2018-09-27 22:35   ` Christoph Hellwig
2018-09-27 22:35 ` [PATCH 5/5] dma-direct: always allow dma mask <= physiscal memory size Christoph Hellwig
2018-09-27 22:35   ` Christoph Hellwig
2018-09-27 22:35   ` Christoph Hellwig
2018-10-03 23:10   ` Alexander Duyck
2018-10-03 23:10     ` Alexander Duyck
2018-10-03 23:10     ` Alexander Duyck
2018-10-09  5:01     ` Benjamin Herrenschmidt
2018-10-09  5:01       ` Benjamin Herrenschmidt
2018-10-09  5:01       ` Benjamin Herrenschmidt
2018-11-19 14:18       ` Ramon Fried
2018-11-19 14:18         ` Ramon Fried
2018-11-19 15:50         ` Robin Murphy [this message]
2018-11-19 15:50           ` Robin Murphy
2018-11-20  7:38           ` Ramon Fried
2018-11-20  7:38             ` Ramon Fried
2018-10-01 14:32 ` dma mask related fixups (including full bus_dma_mask support) v2 Christoph Hellwig
2018-10-01 14:32   ` Christoph Hellwig
2018-10-01 20:51   ` Benjamin Herrenschmidt
2018-10-01 20:51     ` Benjamin Herrenschmidt
  -- strict thread matches above, loose matches on Subject: below --
2018-09-20 18:52 dma mask related fixups (including full bus_dma_mask support) Christoph Hellwig
2018-09-20 18:52 ` [PATCH 5/5] dma-direct: always allow dma mask <= physiscal memory size Christoph Hellwig
2018-09-27  1:50   ` Benjamin Herrenschmidt
2018-09-27  1:50     ` Benjamin Herrenschmidt
2018-09-27 13:49     ` Christoph Hellwig
2018-09-27 15:07       ` Robin Murphy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bb76b9a1-dc3a-2357-a871-291d68703776@arm.com \
    --to=robin.murphy@arm.com \
    --cc=benh@kernel.crashing.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=ramon.fried@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.