On Thu, Jun 04, 2026 at 02:05:35PM +0000, Michael Kelley wrote: > 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.
Oh yes I do think the AMD derived terminogy is aweful :( > Here's a proposal. The new DMA attribute is DMA_ATTR_CC_SHARED. > Name the pool attribute "cc_shared" instead of "unencrypted". Yeah maybe. I sometimes imagine replacing the encrypted/decrypted names with cc_shared too just to make it sane. > "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. It seems like a good idea to me Jason
