On Tue, Jul 28, 2026, Tarun Sahu wrote: > Register a Live Update Orchestrator (LUO) file handler for KVM VM files > to serialize and deserialize VM state across kexec live updates. > > Currently, Only VM type (e.g. arch.vm_type on x86) is preserved as part > of VM preservation.
Why? > On retrieval, kvm_luo_retrieve() recreates the KVM VM file via > kvm_create_vm_file() and use an atomically incremented ID for the internal > fdname, as the final fdname assigned by userspace is not yet known during > retrieval. As this fdname is only used in debugfs infra, This will not break > any UAPI. > > This infrastructure establishes the foundation for preserving guest_memfd > instances across live updates, and can be expanded in the future to > preserve additional VM state. Uh, why guest_memfd? As much as I want to push guest_memfd adoption, it seems guest_memfd should be the _last_ thing we support, not the first. As evidenced by the last two decades, it's very doable to have KVM VMs without guest_memfd, but it's rather hard to have VMs without vCPUs. > Also updates MAINTAINERS to include virt/kvm/kvm_luo.c and > include/linux/kho/abi/kvm.h. > > Signed-off-by: Tarun Sahu <[email protected]> > --- > MAINTAINERS | 11 ++ > include/linux/kho/abi/kvm.h | 39 ++++++++ > virt/kvm/Makefile.kvm | 1 + > virt/kvm/kvm_luo.c | 195 ++++++++++++++++++++++++++++++++++++ > virt/kvm/kvm_main.c | 8 ++ > virt/kvm/kvm_mm.h | 8 ++ > 6 files changed, 262 insertions(+) > create mode 100644 include/linux/kho/abi/kvm.h > create mode 100644 virt/kvm/kvm_luo.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index a3ed337e827d..0283f0fd6ef4 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -14539,6 +14539,17 @@ S: Maintained > F: Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml > F: drivers/video/backlight/ktz8866.c > > +KVM LIVE UPDATE > +M: Pasha Tatashin <[email protected]> > +M: Mike Rapoport <[email protected]> > +M: Pratyush Yadav <[email protected]> > +R: Tarun Sahu <[email protected]> > +L: [email protected] > +L: [email protected] > +S: Maintained > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux.git NAK on taking changes through a different tree. This is KVM code, period. In general, I'm skeptical of the dedicated MAINTAINERS entry. It's extremely difficult to tell since this series is little more than a skeleton (either that or liveupdate is way simpler that I was expecting), but I suspect that maintaining liveupdate for KVM (or for any subsystem) will require more subsystem-specific knowledge than liveupdate knowledge. E.g. the LUO APIs seem pretty straightforward; I assume the bulk of the complexity is going to be in knowing what to save/restore, and how, which is much more about KVM than it is about liveupdate. > +F: virt/kvm/kvm_luo.c > + > KVM PARAVIRT (KVM/paravirt) > M: Paolo Bonzini <[email protected]> > R: Vitaly Kuznetsov <[email protected]> > diff --git a/include/linux/kho/abi/kvm.h b/include/linux/kho/abi/kvm.h > new file mode 100644 > index 000000000000..718db68a541a > --- /dev/null > +++ b/include/linux/kho/abi/kvm.h > @@ -0,0 +1,39 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (c) 2026, Google LLC. > + * Tarun Sahu <[email protected]> > + * > + * KVM Preservation ABI for Live Update Orchestrator (LUO) > + */ > +#ifndef _LINUX_KHO_ABI_KVM_H > +#define _LINUX_KHO_ABI_KVM_H > + > +#include <linux/types.h> > +#include <linux/kho/abi/kexec_handover.h> > + > +/** > + * DOC: KVM Live Update ABI > + * > + * KVM uses the ABI defined below for preserving its state > + * across a kexec reboot using the LUO. > + * > + * The state is serialized into a packed structure `struct kvm_luo_ser` > + * which is handed over to the next kernel via the KHO mechanism. > + * > + * This interface is a contract. Any modification to the structure layout > + * constitutes a breaking change. Such changes require incrementing the > + * version number in the KVM_LUO_FH_COMPATIBLE compatibility string. > + */ > + > +/** > + * struct kvm_luo_ser - Main serialization structure for a KVM VM. > + * @type: The type of VM. > + */ > +struct kvm_luo_ser { > + u64 type; > +} __packed; > + > +/* The compatibility string for KVM VM file handler */ > +#define KVM_LUO_FH_COMPATIBLE "kvm_vm_luo_v1" > + > +#endif /* _LINUX_KHO_ABI_KVM_H */ > diff --git a/virt/kvm/Makefile.kvm b/virt/kvm/Makefile.kvm > index d047d4cf58c9..c1a962159264 100644 > --- a/virt/kvm/Makefile.kvm > +++ b/virt/kvm/Makefile.kvm > @@ -13,3 +13,4 @@ kvm-$(CONFIG_HAVE_KVM_IRQ_ROUTING) += $(KVM)/irqchip.o > kvm-$(CONFIG_HAVE_KVM_DIRTY_RING) += $(KVM)/dirty_ring.o > kvm-$(CONFIG_HAVE_KVM_PFNCACHE) += $(KVM)/pfncache.o > kvm-$(CONFIG_KVM_GUEST_MEMFD) += $(KVM)/guest_memfd.o > +kvm-$(CONFIG_LIVEUPDATE_GUEST_MEMFD) += $(KVM)/kvm_luo.o > diff --git a/virt/kvm/kvm_luo.c b/virt/kvm/kvm_luo.c > new file mode 100644 > index 000000000000..025b53151b6a > --- /dev/null > +++ b/virt/kvm/kvm_luo.c > @@ -0,0 +1,195 @@ > +// SPDX-License-Identifier: GPL-2.0 > + > +/* > + * Copyright (c) 2026, Google LLC. > + * Tarun Sahu <[email protected]> > + * > + * KVM VM Preservation for Live Update Orchestrator (LUO) > + */ > + > +/** > + * DOC: KVM VM Preservation via LUO > + * > + * Overview > + * ======== > + * > + * KVM virtual machines (VMs) can be preserved over a kexec reboot using the > + * Live Update Orchestrator (LUO) file preservation. This allows userspace > + * to preserve KVM VM state across kexec reboots. > + * > + * The preservation is not intended to be fully transparent. Only specific > + * VM configuration and state are preserved, while other aspects of the VM > + * must be re-established or re-configured by userspace after retrieval. IMO, this is not helpful documentation. Anyone with passing knowledge of LUO already knows the above. What people like me don't know are the exact details of how preserving a KVM guest is expected to work. > + * Preserved Properties > + * ==================== > + * > + * The following properties of the KVM VM are preserved across kexec: > + * > + * VM Type > + * The VM type (e.g., on x86 architecture, the vm_type parameter) is > + * preserved. > + * > + * Non-Preserved Properties > + * ======================== > + * > + * The preservation does not cover: > + * > + * - vCPUs and vCPU states > + * - Memspots / Memory slot layout (memslots) > + * - Interrupt controllers and IRQ routings > + * - Coalesced MMIO zones > + * - Device bindings (VFIO/Eventfds) > + * - Active paging or guest registers state > + * - etc So... what's the plan? Bluntly, this series isn't going anywhere without a clear plan of how all of this is going to fit together. > +static int kvm_luo_preserve(struct liveupdate_file_op_args *args) > +{ > + struct kvm *kvm = args->file->private_data; > + struct kvm_luo_ser *ser; I *really* dislike the "ser" nomenclature. The abbreviation isn't common, and IMO it's not intuitive. This also needs to be more specific, becuase I'm guessing we'll end up with more than one "kvm" LUO structure. Maybe something like kvm_vm_luo_state? > + > + if (kvm->vm_dead || kvm->vm_bugged) > + return -EINVAL; > + > + ser = kho_alloc_preserve(sizeof(*ser)); > + if (IS_ERR(ser)) > + return PTR_ERR(ser); > + > +#if defined(CONFIG_X86) > + ser->type = kvm->arch.vm_type; > +#elif defined(CONFIG_ARM64) > + ser->type = kvm_phys_shift(&kvm->arch.mmu); > + if (kvm_vm_is_protected(kvm)) > + ser->type |= KVM_VM_TYPE_ARM_PROTECTED; > + > +#else > + ser->type = 0; > +#endif This needs to be properly supported with arch callbacks. And per-arch enabling needs to be done in separate patches. > + > + args->serialized_data = virt_to_phys(ser); > + return 0; > +} > + > +static atomic_t restored_vm_id = ATOMIC_INIT(0); > + > +static int kvm_luo_retrieve(struct liveupdate_file_op_args *args) > +{ > + char fdname[ITOA_MAX_LEN + 1]; > + struct kvm_luo_ser *ser; > + struct file *file; > + struct kvm *kvm; > + int err = 0; > + > + if (!args->serialized_data) > + return -EINVAL; > + > + ser = phys_to_virt(args->serialized_data); KVM generally uses __va() and __pa(), is there a reason to diverge?
