From: Aneesh Kumar K.V <[email protected]> Sent: Thursday, June 4, 2026 7:58 AM > > Michael Kelley <[email protected]> writes: > > > 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. > > > > That is better. It would also simplify: > > if (mem->unencrypted != !!(attrs & DMA_ATTR_CC_SHARED)) > return NULL; > > to > if (mem->cc_shared != !!(attrs & DMA_ATTR_CC_SHARED)) > return NULL; > > > I already sent a v6 in the hope of getting this merged for the next > merge window. Should I send a v7, or would you prefer that I do the > rename on top of v6? >
I would advocate for a v7 with the rename, vs. a separate follow-on patch to do the rename, just to reduce churn. But I don't know what the tradeoffs are in trying to hit the next merge window. If a follow-on patch is more practical from a timing standpoint, I won't object. Michael
