Re: [PATCH 10/30] KVM: arm64: Introduce __pkvm_host_donate_guest()

Quentin Perret
2026-01-09T15:10:13Z

On Friday 09 Jan 2026 at 14:30:47 (+0000), Will Deacon wrote:
> On Tue, Jan 06, 2026 at 02:48:00PM +0000, Quentin Perret wrote:
> > On Monday 05 Jan 2026 at 15:49:18 (+0000), Will Deacon wrote:
> > > +static void handle___pkvm_host_donate_guest(struct kvm_cpu_context *host_ctxt)
> > > +{
> > > + DECLARE_REG(u64, pfn, host_ctxt, 1);
> > > + DECLARE_REG(u64, gfn, host_ctxt, 2);
> > > + struct pkvm_hyp_vcpu *hyp_vcpu;
> > > + int ret = -EINVAL;
> > > +
> > > + hyp_vcpu = pkvm_get_loaded_hyp_vcpu();
> > > + if (!hyp_vcpu)
> >
> > I guess we should check this is a protected VM here, else a malicious
> > host could donate pages to an np-guest. I didn't try to think through
> > the implications, perhaps it's fine, but it feels unecessary so I'd say
> > let's be restrictive here.
>
> It's definitely harmless to add the check, but it's also hard to justify
> in my opinion. Can you think of anything that can actually go wrong it
> a malicious host donates memory to a non-protected guest? Generally,
> I think the fewer places where we have to distinguish between a
> protected and a non-protected guest in the hypervisor, the better.

I agree with the principle. Now, we already _must_ check that
host-to-guest shares are not allowed for pVMs, so this would simply make
things symmetrical I think, and this is really a simple check.

Right now a page donated to an np-guest is probably just leaked and
doesn't harm security with the current code, but I'd personally rather
not have to reason about this known-to-be-broken state as we add more
transitions in the future -- I write more than enough bugs just thinking
about the known-good ones :-).