On Wed, Sep 23, 2026 at 09:28:54AM -0700, Kameron Carr wrote:

On 9/23/2026 8:21 AM, Jason Gunthorpe wrote:

...

On Wed, Sep 23, 2026 at 08:28:57PM +0530, Aneesh Kumar K.V wrote:

...

I'm also considering requiring the address passed to cc_make_shared() to be in the linear map. This is currently required by both TDX and CCA, while AMD SNP appears to support vmalloc addresses. The only user of that vmalloc support is Hyper-V VMBus GPADL setup (vmbus_establish_gpadl()). How should the generic CoCo shared-memory allocator handle this?

vmbus_establish_gpadl() is the the same wrong abstraction as the arch code. Get rid of it and use vmbus_establish_gpadl_caller_decrypted():

pdata->recv_buf = vzalloc(RECV_BUFFER_SIZE);
if (!pdata->recv_buf) {
	ret = -ENOMEM;
	goto fail_free_ring;
}

ret = vmbus_establish_gpadl(channel, pdata->recv_buf,
			    RECV_BUFFER_SIZE, &pdata->recv_gpadl);

So you made an allocator that returns folios, now you just need to use that allocator to implement a kvzalloc wrapper. ARM can call vmap on decrypted memory with pgprot_decrypted(), right?

Or maybe this can use vmbus_alloc_buffer(), it already does it.

Michael Kelley recently proposed [1] moving all ring buffer allocations to use vmbus_alloc_buffer(). If we move forward with this, it should remove the dependency on vmalloc support.

Even better vmbus_alloc_buffer() can use the new allocator API directly so it doesn't need to open code the set_memory_decrypted arch call.

Lets do it!

Jaon