From: Christoph Hellwig <hch@infradead.org>
To: "Limonciello, Mario" <Mario.Limonciello@amd.com>
Cc: Will Deacon <will@kernel.org>,
"Hegde, Vasant" <Vasant.Hegde@amd.com>,
open list <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@infradead.org>,
"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH 0/2] Fix issues with untrusted devices and AMD IOMMU
Date: Mon, 4 Apr 2022 10:24:29 -0700 [thread overview]
Message-ID: <YkspzQLcfvTQfJ9i@infradead.org> (raw)
In-Reply-To: <BL1PR12MB51573B811E1F7321E25EF785E2E59@BL1PR12MB5157.namprd12.prod.outlook.com>
On Mon, Apr 04, 2022 at 05:05:00PM +0000, Limonciello, Mario wrote:
> I do expect that solves it as well. The reason I submitted the way I
> did is that there seemed to be a strong affinity for having swiotlb
> disabled when IOMMU is enabled on AMD IOMMU. The original code that
> disabled SWIOTLB in AMD IOMMU dates all the way back to 2.6.33 (commit
> 75f1cdf1dda92cae037ec848ae63690d91913eac) and it has ping ponged around
> since then to add more criteria that it would be or wouldn't be
> disabled, but was never actually dropped until your suggestion.
Well, that was before we started bounce buffering for untrusted devices.
We can't just have a less secure path for them because some conditions
are not met. Especially given that most AMD systems right now probably
don't have that swiotlb buffer if the IOMMU is enabled. So not freeing
the buffer in this case is a bug fix that is needed to properly
support the bounce buffering for unaligned I/O to untrusted devices.
> I do think that my messaging patch (1/2) may still be useful for
> debugging in the future if for another reason SWIOTLB is disabled.
I think the warning is useful. For dma-direct we have it in the caller
so I'd be tempted todo the same for dma-iommu.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
prev parent reply other threads:[~2022-04-04 17:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-04 16:47 [PATCH 0/2] Fix issues with untrusted devices and AMD IOMMU Mario Limonciello via iommu
2022-04-04 16:47 ` [PATCH 1/2] swiotlb: Check that slabs have been allocated when requested Mario Limonciello via iommu
2022-04-04 16:47 ` [PATCH 2/2] iommu: Don't use swiotlb unless it's active Mario Limonciello via iommu
2022-04-04 16:54 ` [PATCH 0/2] Fix issues with untrusted devices and AMD IOMMU Christoph Hellwig
2022-04-04 17:05 ` Limonciello, Mario via iommu
2022-04-04 17:24 ` Christoph Hellwig [this message]
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=YkspzQLcfvTQfJ9i@infradead.org \
--to=hch@infradead.org \
--cc=Mario.Limonciello@amd.com \
--cc=Vasant.Hegde@amd.com \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
/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