linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Christoph Hellwig <hch@lst.de>
Cc: "Oliver OHalloran" <oliveroh@au1.ibm.com>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"Cédric Le Goater" <clg@kaod.org>
Subject: Re: [PATCH kernel] powerpc/dma: Fix dma_map_ops::get_required_mask
Date: Thu, 24 Sep 2020 17:03:11 +1000	[thread overview]
Message-ID: <1acaab45-1796-7420-b4fd-b6add7f0d28f@ozlabs.ru> (raw)
In-Reply-To: <20200923141020.GA12374@lst.de>



On 24/09/2020 00:10, Christoph Hellwig wrote:
> On Tue, Sep 22, 2020 at 12:26:18PM +1000, Alexey Kardashevskiy wrote:
>>> Well, the original intent of dma_get_required_mask is to return the
>>> mask that the driver then uses to figure out what to set, so what aacraid
>>> does fits that use case. 
>>
>> What was the original intent exactly? The driver asks for the minimum or
>> maximum DMA mask the platform supports?
>>
>> As for now, we (ppc64/powernv) can do:
>> 1. bypass (==64bit)
>> 2. a DMA window which used to be limited by 2GB but not anymore.
>>
>> I can understand if the driver asked for required mask in expectation to
>> receive "less or equal than 32bit" and "more than 32 bit" and choose.
>> And this probably was the intent as at the time when the bug was
>> introduced, the window was always smaller than 4GB.
>>
>> But today the window is bigger than than (44 bits now, or a similar
>> value, depends on max page order) so the returned mask is >32. Which
>> still enables that DAC in aacraid but I suspect this is accidental.
> 
> I think for powernv returning 64-bit always would make a lot of sense.
> AFAIK all of powernv is PCIe and not legacy PCI, so returning anything
> less isn't going to help to optimize anything.

May be... The current behavior is not wrong (after the fix) but not
optimal either. Even with legacy PCI it should just result in failing
attempt to set 64bit mask which drivers should still handle, i.e. choose
a shorter mask.

Why not ditch the whole dma_get_required_mask() and just fail on setting
a bigger mask? Are these failures not handled in some drivers? Or there
are cases when a shorter mask is better? Thanks,


>>> Of course that idea is pretty bogus for
>>> PCIe devices.
>>
>> Why? From the PHB side, there are windows. From the device side, there
>> are many crippled devices, like, no GPU I saw in last years supported
>> more than 48bit.
> 
> Yes, but dma_get_required_mask is misnamed - the mask is not required,
> it is the optimal mask.  Even if the window is smaller we handle it
> some way, usually by using swiotlb, or by iommu tricks in your case.
>
>>> I suspect the right fix is to just not query dma_get_required_mask for
>>> PCIe devices in aacraid (and other drivers that do something similar).
>>
>> May be, if you write nice and big comment next to
>> dma_get_required_mask() explaining exactly what it does, then I will
>> realize I am getting this all wrong and we will move to fixing the
>> drivers :)
> 
> Yes, it needs a comment or two, and probaby be renamed to
> dma_get_optimal_dma_mask, and a cleanup of most users.  I've added it
> to my ever growing TODO list, but I would not be unhappy if someone
> else gives it a spin.
> 

-- 
Alexey

  reply	other threads:[~2020-09-24  7:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-08  1:51 [PATCH kernel] powerpc/dma: Fix dma_map_ops::get_required_mask Alexey Kardashevskiy
2020-09-08  5:44 ` Christoph Hellwig
2020-09-08 12:06   ` Alexey Kardashevskiy
2020-09-08 12:19     ` Christoph Hellwig
     [not found]       ` <1746dd66810.27bb.1ca38dd7e845b990cd13d431eb58563d@ozlabs.ru>
     [not found]         ` <20200909075849.GA12282@lst.de>
2020-09-09  9:36           ` Alexey Kardashevskiy
2020-09-15  6:50             ` Christoph Hellwig
2020-09-22  2:26               ` Alexey Kardashevskiy
2020-09-23 14:10                 ` Christoph Hellwig
2020-09-24  7:03                   ` Alexey Kardashevskiy [this message]
2020-09-25  4:56                     ` Christoph Hellwig
2021-09-29  8:48           ` Alexey Kardashevskiy
2020-09-08  6:45 ` Michael Ellerman
2020-09-08 11:45 ` Cédric Le Goater
2020-09-10 12:55 ` Michael Ellerman

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=1acaab45-1796-7420-b4fd-b6add7f0d28f@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=clg@kaod.org \
    --cc=hch@lst.de \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=oliveroh@au1.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).