Thread (39 messages) 39 messages, 8 authors, 12d ago

Re: [RFC PATCH v7 02/13] mm: Add an allocator for CoCo shared memory

From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
Date: 2026-09-23 14:59:12
Also in: dri-devel, kvmarm, linux-coco, linux-iommu, linux-media, linux-mm, lkml

Jason Gunthorpe [off-list ref] writes:
On Wed, Sep 23, 2026 at 11:40:36AM +0100, Catalin Marinas wrote:
quoted
The simplest is probably to always zero in the backend and ignore
__GFP_ZERO to the allocator. But it's probably only marginally smaller
than passing a CC_SHARED_ZERO flag down. Get codex to try this as well
and compare the diffstat.
For patch ordering I would convert to use the allocator first

The semantics of the new API should be clear

If you pass GFP_ZERO then the resulting allocated memory is zero

Otherwise the allocator does Whatever The Arch Needs to not leak
private data out.
ok
Once places are converted to the allocator lets go see what is left
and ask why it is left and what API it actually needs.
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?

-aneesh
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help