Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

51 participants
6031 discussions

by Chong Criston

5 days, 20 hours

dachshund puppies for sale craigslist

by Chong Criston

5 days, 20 hours

dachshunds for sale near me

by Chong Criston

5 days, 20 hours

dachshund puppies for adoption

by Chong Criston

5 days, 20 hours

dachshund puppies for sale near me under $500

by Chong Criston

5 days, 20 hours

dachshund puppies for sale california

by Chong Criston

5 days, 20 hours

mini dachshund puppies for sale

by Chong Criston

5 days, 20 hours

dachshund puppies for sale texas

by Chong Criston

5 days, 20 hours

Re: [PATCH net-next v3 2/2] dma-buf: heaps: system: add system_cc_decrypted heap for explicitly decrypted memory

by Jason Gunthorpe

On Mon, Mar 09, 2026 at 09:39:44AM -0600, Peter Gonda wrote: > Great feature to have thanks Jiri! A couple naive questions. > > On Thu, Mar 5, 2026 at 5:38 AM Jiri Pirko <jiri(a)resnulli.us> wrote: > > > > From: Jiri Pirko <jiri(a)nvidia.com> > > > > Add a new "system_cc_decrypted" dma-buf heap to allow userspace to > > allocate decrypted (shared) memory for confidential computing (CoCo) > > VMs. > > > > On CoCo VMs, guest memory is encrypted by default. The hardware uses an > > encryption bit in page table entries (C-bit on AMD SEV, "shared" bit on > > Intel TDX) to control whether a given memory access is encrypted or > > decrypted. The kernel's direct map is set up with encryption enabled, > > so pages returned by alloc_pages() are encrypted in the direct map > > by default. To make this memory usable for devices that do not support > > DMA to encrypted memory (no TDISP support), it has to be explicitly > > decrypted. A couple of things are needed to properly handle > > decrypted memory for the dma-buf use case: > > > > - set_memory_decrypted() on the direct map after allocation: > > Besides clearing the encryption bit in the direct map PTEs, this > > also notifies the hypervisor about the page state change. On free, > > the inverse set_memory_encrypted() must be called before returning > > pages to the allocator. If re-encryption fails, pages > > are intentionally leaked to prevent decrypted memory from being > > reused as private. > > > > - pgprot_decrypted() for userspace and kernel virtual mappings: > > Any new mapping of the decrypted pages, be it to userspace via > > mmap or to kernel vmalloc space via vmap, creates PTEs independent > > of the direct map. These must also have the encryption bit cleared, > > otherwise accesses through them would see encrypted (garbage) data. > > So this only works on new mappings? What if there are existing > mappings to the memory that will be converted to shared? The set_memory_decrypted() is called during system_heap_allocate(), it is not possible to change dynamically between encrypted/decrypted. Once the heap is created every PTE is always created with the correct pgprot. Jason

6 days, 1 hour

Re: [PATCH net-next v3 1/2] dma-mapping: introduce DMA_ATTR_CC_DECRYPTED for pre-decrypted memory

by Jason Gunthorpe

On Mon, Mar 09, 2026 at 01:56:10PM +0100, Petr Tesarik wrote: > I don't want to start a bikeshedding discussion, so if everyone else > likes this name, let's keep it. But maybe the "_CC" (meaning > Confidential Comptuing) is not necessary. IIUC it's the same concept as > set_page_encrypted(), set_page_decrypted(), which does not refer to > CoCo either. Frankly I hate that AMD got their "encrypted" "decrypted" naming baked into the CC related APIs. I'm not at all convinced that they "do not refer to CoCo" in the way Linux uses them and other arches absolutely make them 100% tied to coco. If we are going to bikeshed the name it should be DMA_ATTR_CC_SHARED Jason

6 days, 4 hours

← Newer
1
2
3
4
5
6
7
8
9
...
604
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig