RE: [PATCH v5 05/20] dma-pool: track decrypted atomic pools and select them via attrs

[Michael Kelley]

From: Jason Gunthorpe <jgg@xxxxxxxx> Sent: Tuesday, June 2, 2026 5:55 PM
> 
> On Tue, Jun 02, 2026 at 02:24:40PM +0000, Michael Kelley wrote:
> 
> > Except that in a normal VM, the "unencrypted" pool attribute does *not*
> > describe the state of the memory itself.  In a normal VM, the memory is
> > unencrypted, but the "unencrypted" pool attribute is false. That
> > contradiction is the essence of my concern.
> 
> I would argue no..
> 
> When CC is enabled the default state of memory in a Linux environment
> is "encrypted". You have to take a special action to "decrypt" it.
> 
> Thus the default state of memory in a non-CC environment is also
> paradoxically "encrypted" too. 

The need to have such an unnatural premise is usually an indication
of a conceptual problem with the overall model, or perhaps just a
terminology problem. 

Here's a proposal. The new DMA attribute is DMA_ATTR_CC_SHARED.
Name the pool attribute "cc_shared" instead of "unencrypted". Having
"cc_shared" set to false in a normal VM doesn't lead to the non-sensical
situation of claiming that a normal VM is encrypted. The boolean
"unencrypted" parameter that has been added to various calls also
becomes "cc_shared".  If "CC_SHARED" is a suitable name for the DMA
attribute, it ought to be suitable as the pool attribute. And everything
matches as well.

Michael  


> "decryption" is impossible.
> 
> Therefore the "unencrypted" state is a special state that only memory
> inside a CC VM can have. A normal VM can never have "unencrypted"
> memory at all, so having it be false in the pool is accurate as far as
> the APIs go.
> 
> un-encrypted = true means "the memory in this pool was transformed with
> set_memory_decrypted()" - which is impossible on a normal VM.
> 
> Jason