Re: [RFC PATCH v8 01/14] mm: Add an allocator for CoCo shared memory

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Sep 24, 2026 at 07:52:39PM +0530, Aneesh Kumar K.V wrote:
> >> +int cc_make_shared(void *addr, size_t size)
> >> +{
> >> +	int ret = cc_validate_transition(addr, size);
> >> +
> >> +	if (ret)
> >> +		return ret;
> >> +
> >> +	return set_memory_decrypted((unsigned long)addr, size >> PAGE_SHIFT);
> >> +}
> >
> > [Severity: Medium]
> > Will this function be unavailable to dynamically loadable modules since it
> > is missing an EXPORT_SYMBOL_GPL() macro?
> >
> > The commit message states it should be usable by callers managing their own
> > backing memory, but virtio or guest drivers won't be able to link to it
> > without an export.

> >> +
> >> +int cc_make_private(void *addr, size_t size)
> >> +{
> >> +	int ret = cc_validate_transition(addr, size);
> >> +
> >> +	if (ret)
> >> +		return ret;
> >> +
> >> +	return set_memory_encrypted((unsigned long)addr, size >> PAGE_SHIFT);
> >> +}
> >
> > [Severity: Medium]
> > Does this function also need an EXPORT_SYMBOL_GPL() macro so that modules
> > can successfully link and call it?
> 
> I guess we don't want the cc_make_shared() and cc_make_private() APIs to be
> called by modules. Modules that need CoCo shared memory should use
> alloc_cc_shared_pages().

Indeed, but we may also be over indexing on the cc name given AMD also
uses this for their troubled host memory encryption address limit problem :\

The note about virtio seems a bit strange, these are new functions why
does it think virtio is calling them?

> >> +	/*
> >> +	 * State transitions require a linear-map address and may modify memory.
> >> +	 * Allocate from low memory and defer requested zeroing until afterwards.
> >> +	 */
> >> +	gfp &= ~(__GFP_HIGHMEM | __GFP_ZERO);
> >
> > [Severity: High]
> > Does this code inadvertently leave __GFP_MOVABLE intact if passed by the
> > caller?
> >
> > Pages are returned as shared memory, but they lack migration hooks
> > (movable_operations) to handle encryption state transitions during page
> > migration.
> >
> > If a caller passes __GFP_MOVABLE, the page might be placed in ZONE_MOVABLE.
> > Since the kernel migration code does not know how to handle encryption state
> > transitions, the page cannot be safely migrated. Could this permanently pin
> > the movable zone, thereby breaking memory hot-unplug and compaction?
> 
> I don't think we want CoCo shared memory allocations to be movable, but
> I'm also not sure whether we should filter out all of these GFP flags.

It sounds like we should at least *reject* movable. It is right that
seems incompatible with this, and we have no use case..

> >> +	if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
> >> +		return __alloc_cc_shared_pages_node(nid, gfp, requested, mem);
> >> +
> >> +	order = get_order(requested);
> >> +	if (order > MAX_PAGE_ORDER)
> >> +		return -EINVAL;
> >> +
> >> +	if (nid == NUMA_NO_NODE)
> >> +		page = alloc_pages(gfp, order);
> >> +	else
> >> +		page = alloc_pages_node(nid, gfp, order);
> >
> > [Severity: Medium]
> > Can this fallback path inadvertently allocate a highmem page?
> >
> > The function's kernel-doc explicitly guarantees: "A memory-state transition
> > requires a valid linear-map address, so such allocations never come from
> > high memory".
> 
> Only when a private-to-shared transition is required.

IMHO disable the whole thing at kconfig if highmem is enabled. Make
the calls always fail.

Jason