On Tue, Oct 13, 2026 at 10:32:36AM +0530, Aneesh Kumar K.V wrote: > Jason Gunthorpe <[email protected]> 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.
Oh, really? dmabuf heap doesn't want that.. How does GIC even work like this? It makes the memory shared but then it puts the private IPA into the HW registers? The VMM is supposed to assume every address is actually a shared IPA and fix it? That's a little weird.. Anyhow, in that case probably mask off GFP_HIGHMEM at the start of the function, not allowed, not supported. Jason
