On Mon, Mar 09, 2026 at 06:51:21PM +0100, Jiri Pirko wrote:
Mon, Mar 09, 2026 at 04:18:57PM +0100, jgg@ziepe.ca wrote:
On Mon, Mar 09, 2026 at 04:02:33PM +0200, Leon Romanovsky wrote:
On Mon, Mar 09, 2026 at 10:15:30AM -0300, Jason Gunthorpe wrote:
On Sun, Mar 08, 2026 at 12:19:48PM +0200, Leon Romanovsky wrote:
+/*
- DMA_ATTR_CC_DECRYPTED: Indicates memory that has been explicitly decrypted
- (shared) for confidential computing guests. The caller must have
- called set_memory_decrypted(). A struct page is required.
- */
+#define DMA_ATTR_CC_DECRYPTED (1UL << 12)
While adding the new attribute is fine, I would expect additional checks in dma_map_phys() to ensure the attribute cannot be misused. For example, WARN_ON(attrs & (DMA_ATTR_CC_DECRYPTED | DMA_ATTR_MMIO)), along with a check that we are taking the direct path only.
DECRYPYED and MMIO is something that needs to work, VFIO (inside a TVM) should be using that combination.
So this sentence "A struct page is required" from the comment above is not accurate.
It would be clearer to say "Unless DMA_ATTR_MMIO is provided a struct page is required"
We need to audit if that works properly, IIRC it does, but I don't remember.. Jiri?
How can you do set_memory_decrypted if you don't have page/folio ?
Alot of device MMIO is decrypted by nature and can't be encrypted, so you'd have to use both flags. eg in VFIO we'd want to do this.
Jason