From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Sreekanth Reddy <Sreekanth.Reddy@avagotech.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
scsi <linux-scsi@vger.kernel.org>, Christoph Hellwig <hch@lst.de>
Subject: Re: Concerns about "mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support"
Date: Fri, 20 Feb 2015 16:22:41 +1100 [thread overview]
Message-ID: <1424409761.27448.32.camel@kernel.crashing.org> (raw)
In-Reply-To: <1424408769.27448.28.camel@kernel.crashing.org>
On Fri, 2015-02-20 at 16:06 +1100, Benjamin Herrenschmidt wrote:
> Note that even on powerpc platforms where it would work because we
> maintain both 32-bit and 64-bit bypass windows in the device address
> space simultaneously, you will leak iommu entries unless you also switch
> back to 32-bit when freeing the 32-bit mappings... (and you would
> probably crash if you tried to free a 64-bit mapping while in 32-bit
> mode).
>
> The iommu APIs weren't designed with that "switching mask" facility in
> mind...
Looking a bit more closely, you basically do
- set_dma_mask(64-bit)
- set_consistent_dma_mask(32-bit)
Now, I don't know how x86 will react to the conflicting masks, but on
ppc64, I'm pretty sure the second one will barf. IE, the first one will
establish a set of direct mapping ops which give you a bypass of the
iommu to all of memory. The second one will then do a
dma_supported(mask) call which will hit the direct ops, and they will
fail since a 32-bit mask cannot address the bypass completely.
Are architectures really required to support such mismatching dma_mask
and consistent_dma_mask ? what a bloody trainwreck ... :-(
Cheers,
Ben.
next prev parent reply other threads:[~2015-02-20 5:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-20 5:01 Concerns about "mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support" Benjamin Herrenschmidt
2015-02-20 5:06 ` Benjamin Herrenschmidt
2015-02-20 5:22 ` Benjamin Herrenschmidt [this message]
2015-02-20 5:45 ` James Bottomley
2015-02-20 7:19 ` Benjamin Herrenschmidt
2015-04-02 5:39 ` Benjamin Herrenschmidt
2015-04-02 5:59 ` James Bottomley
2015-02-20 7:16 ` Benjamin Herrenschmidt
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=1424409761.27448.32.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=Sreekanth.Reddy@avagotech.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.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.