From: David Rientjes via iommu <iommu@lists.linux-foundation.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Amit Pundir <amit.pundir@linaro.org>,
jeremy.linton@arm.com, iommu@lists.linux-foundation.org,
linux-rpi-kernel@lists.infradead.org,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: dma-pool fixes
Date: Sat, 1 Aug 2020 01:20:07 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.23.453.2008010105560.4078406@chino.kir.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.2.23.453.2007311204010.3836388@chino.kir.corp.google.com>
On Fri, 31 Jul 2020, David Rientjes wrote:
> > > Hi Nicolas, Christoph,
> > >
> > > Just out of curiosity, I'm wondering if we can restore the earlier
> > > behaviour and make DMA atomic allocation configured thru platform
> > > specific device tree instead?
> > >
> > > Or if you can allow a more hackish approach to restore the earlier
> > > logic, using of_machine_is_compatible() just for my device for the
> > > time being. Meanwhile I'm checking with other developers running the
> > > mainline kernel on sdm845 phones like OnePlus 6/6T, if they see this
> > > issue too.
> >
> > If we don't find a fix for your platform I'm going to send Linus a
> > last minute revert this weekend, to stick to the no regressions policy.
> > I still hope we can fix the issue for real.
> >
>
> What would be the scope of this potential revert?
>
To follow-up on this, the introduction of the DMA atomic pools in 5.8
fixes an issue for any AMD SEV enabled guest that has a driver that
requires atomic DMA allocations (for us, nvme) because runtime decryption
of memory allocated through the DMA API may block. This manifests itself
as "sleeping in invalid context" BUGs for any confidential VM user in
cloud.
I unfortunately don't have Amit's device to be able to independently debug
this issue and certainly could not have done a better job at working the
bug than Nicolas and Christoph have done so far. I'm as baffled by the
results as anybody else.
I fully understand the no regressions policy. I'd also ask that we
consider that *all* SEV guests are currently broken if they use nvme or
any other driver that does atomic DMA allocations. It's an extremely
serious issue for cloud. If there is *anything* that I can do to make
forward progress on this issue for 5.8, including some of the workarounds
above that Amit requested, I'd be very happy to help. Christoph will make
the right decision for DMA in 5.8, but I simply wanted to state how
critical working SEV guests are to users.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-08-01 8:20 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-28 10:47 dma-pool fixes Christoph Hellwig
2020-07-28 10:47 ` [PATCH 1/2] dma-pool: fix coherent pool allocations for IOMMU mappings Christoph Hellwig
2020-07-28 14:56 ` Nicolas Saenz Julienne
2020-07-28 15:28 ` Christoph Hellwig
2020-07-28 10:47 ` [PATCH 2/2] dma-pool: Only allocate from CMA when in same memory zone Christoph Hellwig
2020-07-28 12:02 ` dma-pool fixes Amit Pundir
2020-07-28 12:07 ` Christoph Hellwig
2020-07-28 12:25 ` Amit Pundir
2020-07-28 12:41 ` Christoph Hellwig
2020-07-28 12:48 ` Amit Pundir
2020-07-28 15:30 ` Christoph Hellwig
2020-07-29 10:45 ` Nicolas Saenz Julienne
2020-07-29 12:22 ` Amit Pundir
2020-07-31 7:46 ` Amit Pundir
2020-07-31 13:09 ` Christoph Hellwig
2020-07-31 14:15 ` Amit Pundir
2020-07-31 19:04 ` David Rientjes via iommu
2020-08-01 8:20 ` David Rientjes via iommu [this message]
2020-08-01 8:57 ` revert scope for 5.8, was " Christoph Hellwig
2020-08-01 11:57 ` Amit Pundir
2020-08-01 16:59 ` Nicolas Saenz Julienne
2020-08-01 17:39 ` Christoph Hellwig
2020-08-02 4:46 ` Amit Pundir
2020-08-02 15:04 ` Amit Pundir
2020-08-03 4:14 ` David Rientjes via iommu
2020-08-03 6:44 ` Christoph Hellwig
2020-08-03 18:30 ` David Rientjes via iommu
2020-08-01 18:28 ` Linus Torvalds
2020-08-02 4:35 ` Amit Pundir
2020-08-01 8:29 ` Christoph Hellwig
2020-07-31 10:47 ` Nicolas Saenz Julienne
2020-07-31 11:17 ` Amit Pundir
2020-07-31 14:15 ` Nicolas Saenz Julienne
2020-07-31 14:20 ` Amit Pundir
2020-08-01 7:34 ` Amit Pundir
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=alpine.DEB.2.23.453.2008010105560.4078406@chino.kir.corp.google.com \
--to=iommu@lists.linux-foundation.org \
--cc=amit.pundir@linaro.org \
--cc=hch@lst.de \
--cc=jeremy.linton@arm.com \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=rientjes@google.com \
--cc=robin.murphy@arm.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).