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

[Ackerley Tng]

Pasha Tatashin <pasha.tatashin@xxxxxxxxxx> writes:

>
> [...snip...]
>
> The Caretaker
> =============
>
> The Caretaker is a specialized, identity-mapped bare-metal executable
> attached to each vCPU. While it is installed during the initial VM setup
> and remains permanently enabled as an interpose layer between the Guest
> and KVM, it is the key architectural feature required for a VM to be
> orphaned. By providing an execution environment independent of the host
> OS, the Caretaker enables the guest workload to safely survive the host
> lifecycle transition.
>
> During normal VM operation, the Caretaker acts as a fast-path shim: it
> forwards standard VM Exits down to the backing KVM kernel module and
> handles certain exits autonomously. However, during the "Management Gap"
> (when no host OS is active and standard KVM handlers are offline), the
> Caretaker enters a standalone mode to ensure continuous guest execution
> without host intervention.
>

I think this might already be explained in different ways by the other
commenters.

I guess the main question I have is, if the Caretaker could indeed take
over caretaking during a "Management Gap", then we're adding code to
tell KVM what to do to handle some VM exits.

In that case, it would be awesome to have that functionality provided by
KVM in the first place, to avoid some number of kernel exits to the
userspace VMM.

> While this proposal focuses on its critical role in minimally disruptive
> Live Update, the Caretaker is fundamentally designed as an extensible
> primitive.

If the Caretaker can/needs to be extended, then on the other extreme,
the entirety of the userspace VMM's functionality could go into the
caretaker, and perhaps that's another direction to go, where maybe LUO
could keep some slice of userspace alive? (then the VM is no longer
orphaned)

> Its architecture allows it to be leveraged for a variety of
> other advanced virtualization use cases, such as running custom
> lightweight hypervisors or completely offloading virtualization duties
> to an accelerator card.
>
>
> [...snip...]
>