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

[Suzuki K Poulose]

Cc: Michael Kelley
On 23/09/2026 15:58, Aneesh Kumar K.V wrote:
> Jason Gunthorpe <jgg@xxxxxxxx> writes:
>
> > On Wed, Sep 23, 2026 at 11:40:36AM +0100, Catalin Marinas wrote:
> >
> > > 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?

This came up in the past and there was a recommendation to alloc shared
pages and vmap them ? I have lost track of it.

Cheers
Suzuki>
> -aneesh