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

[Aneesh Kumar K.V <aneesh.kumar@kernel.org>]

Jason Gunthorpe <jgg@nvidia.com> writes:

> On Thu, Sep 24, 2026 at 07:52:39PM +0530, Aneesh Kumar K.V wrote:

 [ ... 67 lines skipped ... ] 

>
>> >> +	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.
>

But we also want other kernel subsystems to use alloc_cc_shared_pages()
when CoCo is not enabled. In other words, usage like the following
should work even when the kernel is not running as a CoCo guest.

static struct page *its_alloc_pages_node(int node, gfp_t gfp,
					 unsigned int order)
{
	struct cc_shared_pages mem;

	if (alloc_cc_shared_pages_node(node, gfp | gfp_flags_quirk,
				       PAGE_SIZE << order, &mem))
		return NULL;

	return mem.page;
}

-aneesh