From: Jason Gunthorpe <[email protected]> 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
