On Wed, Sep 23, 2026 at 10:00:31AM -0300, Jason Gunthorpe wrote: > On Wed, Sep 23, 2026 at 10:42:39AM +0100, Catalin Marinas wrote: > > > On pKVM, we want set_memory_decrypted() to zero the buffer > > before the host can access it (I guess currently relying on __GFP_ZERO > > allocations). Since no cryptographic encryption takes place, there's not > > much point in memset'ing again after the operation as the content was > > already zeroed. > > It sounds like this a pkvm unique thing, since RMM always makes the > memory hidden, pkvm flow should do it too. Either inside its guest > set_memory_decrypted() or inside the hypervisor like RMM. >
pKVM doesn't clear memory on sharing (see __pkvm_guest_share_host()), and that is not a documented behaviour for ARM_SMCCC_KVM_FUNC_MEM_SHARE (see Documentation/virt/kvm/arm/hypercalls.rst) which implements set_memory_decrypted(). The guest is definitely the one knowing what is inside the pages and whether it can be shared or not. For example, a while ago I was experimenting with inline decryption to avoid bouncing, and I imagine it might be used to build on in the future. Also as these hypercalls are ABI, I'd argue we shouldn't change their semantics. > Hypervisor doing it is the right place, hypervisor always needs to > ensure guest memory is cleansed whenever the guest gives it up. Either > via a private to shared, unmap or just exiting. > "gives it up" is different than sharing, for example: - When the guest dies pKVM will zero the memory before returning it back to the host. - At the moment the guest can not relinquish memory (ballooning) but that is supported in Android which can zero the page. Thanks, Mostafa > > I don't think cc_make_shared() has the right information on how to > > safely and efficiently do the zeroing. That's only known to the > > set_memory_* backend. So you'd have to propagate the flag down. > > +1 > > Jason >
