Jason Gunthorpe <[email protected]> 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? -aneesh
