Re: [RFC] proposal: KVM: Orphaned VMs: The Caretaker approach for Live Update

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

On Thu, 2026-04-30 at 15:28 +0200, Paolo Bonzini wrote:
> I even wonder if, for long term simplicity, the interface for 
> host->caretaker should be just for the caretaker to swallow the host 
> into non-root mode, again as in Arm nVHE. 

There's a lot of merit in that approach.

I talked about wanting to use this 'caretaker' for secret hiding.  But
why have *voluntary* secret hiding with the kernel hiding things from
its own address space, when you have have *mandatory* secret hiding
with something running in EL2, like pKVM. Or the Nitro Isolation Engine
which adds formal proof of correctness on top and is designed to allow
for live update of both itself *and* the kernel it hosts.

Honestly, I don't see the *caretaker* being much of an ABI at all,
except from one kernel to the next.

The *userspace* ABI considerations are all about how you make a vCPU
that runs asynchronously (should it conceptually just be an async
KVM_RUN call, which allows the vCPU to run in a kernel thread up to the
point of kexec? Why is it fundamentally tied to kexec at all?).

I'd love to start without kexec in the picture at all. Just show me the
KVM API for starting a *confidential* guest (pKVM, SEV-SNP, whatever),
leaving it running, completely stopping the VMM and then starting a new
VMM to pick up from where it left off.

Sometimes the vCPUs might all actually still be running. Sometimes they
might have hit an exit that couldn't be handled.

Doing kexec while the VMM is "hands-off" is then the *next* challenge.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]