All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Greg KH <greg@kroah.com>
Cc: Peter Gonda <pgonda@google.com>,
	stable@vger.kernel.org, "Lendacky,
	Thomas" <Thomas.Lendacky@amd.com>,
	"Singh, Brijesh" <brijesh.singh@amd.com>,
	Christoph Hellwig <hch@lst.de>,
	nsaenzjulienne@suse.de, geert@linux-m68k.org,
	sjhuang@iluvatar.ai
Subject: Re: [PATCH 00/30 for 5.4] Backport unencrypted non-blocking DMA allocations
Date: Mon, 4 Jan 2021 14:37:00 -0800 (PST)	[thread overview]
Message-ID: <ef6fed57-cbb7-ed8b-6925-cea0fd55df85@google.com> (raw)
In-Reply-To: <X/MRdPz/POas6FFf@kroah.com>

On Mon, 4 Jan 2021, Greg KH wrote:

> > The series of commits certainly expanded from my initial set that I asked 
> > about in a thread with the subject "DMA API stable backports for AMD SEV" 
> > on May 19.  Turns out that switching how DMA memory is allocated based on 
> > various characteristics of the allocation and device is trickier than 
> > originally thought :)  There were a number of fixes that were needed for 
> > subtleties and cornercases that folks ran into, but were addressed and 
> > have been merged by Linus.  I believe it's stable in upstream and that 
> > we've been thorough in compiling a full set of changes that are required 
> > for 5.4.
> > 
> > Note that without this series, all SEV-enabled guests will run into the 
> > "sleeping function called from invalid context" issue in the vmalloc layer 
> > that Peter cites when using certain drivers.  For such configurations, 
> > there is no way to avoid the "BUG" messages in the guest kernel when using 
> > AMD SEV unless this series is merged into an LTS kernel that the distros 
> > will then pick up.
> > 
> > For my 13 patches in the 30 patch series, I fully stand by Peter's 
> > backports and rationale for merge into 5.4 LTS.
> 
> Given that this "feature" has never worked in the 5.4 or older kernels,
> why should this be backported there?  This isn't a bugfix from what I
> can tell, is it?  And if so, what kernel version did work properly?
> 

I think it can be considered a bug fix.

Today, if you boot an SEV encrypted guest running 5.4 and it requires 
atomic DMA allocations, you'll get the "sleeping function called from 
invalid context" bugs.  We see this in our Cloud because there is a 
reliance on atomic allocations through the DMA API by the NVMe driver.  
Likely nobody else has triggered this because they don't have such driver 
dependencies.

No previous kernel version worked properly since SEV guest support was 
introduced in 4.14.

> And if someone really wants this new feature, why can't they just use a
> newer kernel release?
> 

This is more of a product question that I'll defer to Peter and he can 
loop the necessary people in if required.

Since the SEV feature provides confidentiality for guest managed memory, 
running an unmodified guest vs a guest modified to avoid these bugs by the 
cloud provider is a very different experience from the perspective of the 
customer trying to protect their data.

These customers are running standard distros that may be slow to upgrade 
to new kernels released over the past few months.  We could certainly work 
with the distros to backport this support directly to them on a 
case-by-case basis, but the thought was to first attempt to fix this in 
5.4 stable for everybody and allow them to receive the fixes necessary for 
running a non-buggy SEV encrypted guest that way vs multiple distros doing 
the backport so they can run with SEV.

  reply	other threads:[~2021-01-04 23:43 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25 16:18 [PATCH 00/30 for 5.4] Backport unencrypted non-blocking DMA allocations Peter Gonda
2020-09-25 16:18 ` [PATCH 01/30 for 5.4] dma-direct: remove __dma_direct_free_pages Peter Gonda
2020-09-25 16:18 ` [PATCH 02/30 for 5.4] dma-direct: remove the dma_handle argument to __dma_direct_alloc_pages Peter Gonda
2020-09-25 16:18 ` [PATCH 03/30 for 5.4] dma-direct: provide mmap and get_sgtable method overrides Peter Gonda
2020-09-25 16:18 ` [PATCH 04/30 for 5.4] dma-mapping: merge the generic remapping helpers into dma-direct Peter Gonda
2020-09-25 16:18 ` [PATCH 05/30 for 5.4] lib/genalloc.c: rename addr_in_gen_pool to gen_pool_has_addr Peter Gonda
2020-09-25 16:18 ` [PATCH 06/30 for 5.4] dma-remap: separate DMA atomic pools from direct remap code Peter Gonda
2020-09-25 16:18 ` [PATCH 07/30 for 5.4] dma-pool: add additional coherent pools to map to gfp mask Peter Gonda
2020-09-25 16:18 ` [PATCH 08/30 for 5.4] dma-pool: dynamically expanding atomic pools Peter Gonda
2020-09-25 16:18 ` [PATCH 09/30 for 5.4] dma-direct: atomic allocations must come from atomic coherent pools Peter Gonda
2020-09-25 16:18 ` [PATCH 10/30 for 5.4] dma-pool: add pool sizes to debugfs Peter Gonda
2020-09-25 16:18 ` [PATCH 11/30 for 5.4] x86/mm: unencrypted non-blocking DMA allocations use coherent pools Peter Gonda
2020-09-25 16:18 ` [PATCH 12/30 for 5.4] dma-pool: scale the default DMA coherent pool size with memory capacity Peter Gonda
2020-09-25 16:18 ` [PATCH 13/30 for 5.4] dma-pool: fix too large DMA pools on medium memory size systems Peter Gonda
2020-09-25 16:19 ` [PATCH 14/30 for 5.4] dma-pool: decouple DMA_REMAP from DMA_COHERENT_POOL Peter Gonda
2020-09-25 16:19 ` [PATCH 15/30 for 5.4] dma-direct: consolidate the error handling in dma_direct_alloc_pages Peter Gonda
2020-09-25 16:19 ` [PATCH 16/30 for 5.4] xtensa: use the generic uncached segment support Peter Gonda
2020-09-25 16:19 ` [PATCH 17/30 for 5.4] dma-direct: make uncached_kernel_address more general Peter Gonda
2020-09-25 16:19 ` [PATCH 18/30 for 5.4] dma-direct: always align allocation size in dma_direct_alloc_pages() Peter Gonda
2020-09-25 16:19 ` [PATCH 19/30 for 5.4] dma-direct: re-encrypt memory if dma_direct_alloc_pages() fails Peter Gonda
2020-09-25 16:19 ` [PATCH 20/30 for 5.4] dma-direct: check return value when encrypting or decrypting memory Peter Gonda
2020-09-25 16:19 ` [PATCH 21/30 for 5.4] dma-direct: add missing set_memory_decrypted() for coherent mapping Peter Gonda
2020-09-25 16:19 ` [PATCH 22/30 for 5.4] dma-mapping: DMA_COHERENT_POOL should select GENERIC_ALLOCATOR Peter Gonda
2020-09-25 16:19 ` [PATCH 23/30 for 5.4] dma-mapping: warn when coherent pool is depleted Peter Gonda
2020-09-25 16:19 ` [PATCH 24/30 for 5.4] dma-direct: provide function to check physical memory area validity Peter Gonda
2020-09-25 16:19 ` [PATCH 25/30 for 5.4] dma-pool: get rid of dma_in_atomic_pool() Peter Gonda
2020-09-25 16:19 ` [PATCH 26/30 for 5.4] dma-pool: introduce dma_guess_pool() Peter Gonda
2020-09-25 16:19 ` [PATCH 27/30 for 5.4] dma-pool: make sure atomic pool suits device Peter Gonda
2020-09-25 16:19 ` [PATCH 28/30 for 5.4] dma-pool: do not allocate pool memory from CMA Peter Gonda
2020-09-25 16:19 ` [PATCH 29/30 for 5.4] dma-pool: fix coherent pool allocations for IOMMU mappings Peter Gonda
2020-09-25 16:19 ` [PATCH 30/30 for 5.4] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable Peter Gonda
2020-10-05 13:07 ` [PATCH 00/30 for 5.4] Backport unencrypted non-blocking DMA allocations Greg KH
2020-10-06 15:26   ` Peter Gonda
2020-10-06 18:10     ` David Rientjes
2021-01-04 13:00       ` Greg KH
2021-01-04 22:37         ` David Rientjes [this message]
2021-01-05  5:58           ` Greg KH
2021-01-05  6:38             ` David Rientjes
2021-05-12 19:06               ` Peter Gonda

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=ef6fed57-cbb7-ed8b-6925-cea0fd55df85@google.com \
    --to=rientjes@google.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=brijesh.singh@amd.com \
    --cc=geert@linux-m68k.org \
    --cc=greg@kroah.com \
    --cc=hch@lst.de \
    --cc=nsaenzjulienne@suse.de \
    --cc=pgonda@google.com \
    --cc=sjhuang@iluvatar.ai \
    --cc=stable@vger.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 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.