liveupdate: kvm: Guest_memfd preservation

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch introduces the LIVEUPDATE_GUEST_MEMFD Kconfig option claiming to enable a new feature, but there is no actual implementation provided. --

--- Patch [1]: [PATCH v4 01/11] liveupdate: Add LIVEUPDATE_GUEST_MEMFD config option --- commit e0c3fde657d56c548cd9a7467d2143f0f42c5242
Author: Tarun Sahu <[email protected]>

liveupdate: Add LIVEUPDATE_GUEST_MEMFD config option

This commit introduces the LIVEUPDATE_GUEST_MEMFD Kconfig option, which aims to enable live update support for KVM guest_memfd files.

kernel/liveupdate/Kconfig config LIVEUPDATE_MEMFD · line 95

Quoted 13 lines

kernel/liveupdate/Kconfig +5 -0

index 1a8513f16ef7c..0bbc4037192e9 100644
@@ -88,4 +88,19 @@ config LIVEUPDATE_MEMFD
 
 	  If unsure, say N.
 
+config LIVEUPDATE_GUEST_MEMFD
+	bool "Live update support for guest_memfd"
+	depends on LIVEUPDATE
+	depends on KVM_GUEST_MEMFD
+	default LIVEUPDATE

[Severity: Medium]
Is the implementation for this feature missing from this patch?

The commit message notes that this patch enables live update support for KVM guest_memfd files, but the newly added LIVEUPDATE_GUEST_MEMFD symbol appears to be unreferenced in the tree. Since there are no Makefiles, C files, or preprocessor checks that use it, this currently acts as dead code.

Could the implementation be missing, or was this intended to be introduced as part of a larger series where the symbol is used in a subsequent patch?

kernel/liveupdate/Kconfig config LIVEUPDATE_MEMFD · line 104

Quoted 11 lines

kernel/liveupdate/Kconfig +10 -0

+	help
+	  Enable live update support for KVM guest_memfd files. This allows
+	  preserving VM Memory backed by guest_memfd file across kernel live
+	  updates.
+
+	  This can only be used for the guest_memfd that are fully-shared
+	  and pre-faulted.
+
+	  If unsure, say N.
+
 endmenu

--
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1

Quoted 15 lines · [email protected] writes:

kernel/liveupdate/Kconfig config LIVEUPDATE_MEMFD · line 93

Quoted 6 lines

kernel/liveupdate/Kconfig +5 -0

+config LIVEUPDATE_GUEST_MEMFD
+	bool "Live update support for guest_memfd"
+	depends on LIVEUPDATE
+	depends on KVM_GUEST_MEMFD
+	default LIVEUPDATE

[Severity: Medium]
Is the implementation for this feature missing from this patch?

The commit message notes that this patch enables live update support for KVM guest_memfd files, but the newly added LIVEUPDATE_GUEST_MEMFD symbol appears to be unreferenced in the tree. Since there are no Makefiles, C files, or preprocessor checks that use it, this currently acts as dead code.

Quoted 3 lines

Could the implementation be missing, or was this intended to be introduced as part of a larger series where the symbol is used in a subsequent patch?

Sashiko is right here, I think this patch should be squashed with the first usage.

Quoted 15 lines

kernel/liveupdate/Kconfig config LIVEUPDATE_MEMFD · line 104

Quoted 12 lines

kernel/liveupdate/Kconfig +10 -0

+	help
+	  Enable live update support for KVM guest_memfd files. This allows
+	  preserving VM Memory backed by guest_memfd file across kernel live
+	  updates.
+
+	  This can only be used for the guest_memfd that are fully-shared
+	  and pre-faulted.
+
+	  If unsure, say N.
+
 endmenu

--
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1

Introduce the LIVEUPDATE_GUEST_MEMFD Kconfig option. This option enables live update support for KVM guest_memfd files, enabling guest_memfd-backed memory preservation across kernel upgrades.

Currently this support only guest_memfd files that are full-shared (INIT_SHARED and no support for private_mem).

Quoted 4 lines · Tarun Sahu

Introduce the LIVEUPDATE_GUEST_MEMFD Kconfig option. This option enables live update support for KVM guest_memfd files, enabling guest_memfd-backed memory preservation across kernel upgrades.

Quoted 2 lines

Currently this support only guest_memfd files that are full-shared (INIT_SHARED and no support for private_mem).

Why? Specifically, why do we need/want a separate Kconfig for guest_memfd liveupdate versus KVM liveupdate? I can _maybe_ see a KVM-wide Kconfig, but even that seems like a stretch given that (AFAIK) hypervisors are the one and only use-case for liveupdate.

Quoted 5 lines · Sean Christopherson

Quoted 4 lines · Tarun Sahu

Introduce the LIVEUPDATE_GUEST_MEMFD Kconfig option. This option enables live update support for KVM guest_memfd files, enabling guest_memfd-backed memory preservation across kernel upgrades.

Quoted 7 lines

Quoted 2 lines

Currently this support only guest_memfd files that are full-shared (INIT_SHARED and no support for private_mem).

Why? Specifically, why do we need/want a separate Kconfig for guest_memfd liveupdate versus KVM liveupdate? I can _maybe_ see a KVM-wide Kconfig, but even that seems like a stretch given that (AFAIK) hypervisors are the one and only use-case for liveupdate.

LIVEUPDATE is used in many subsystem. It is possible to enable liveupdate and kvm without enabling KVM_GUEST_MEMFD. So GUEST_MEMFD preservation must depend on CONFIG_LIVEUPDATE and KVM_GUEST_MEMFD both. LIVEUPDATE_GUEST_MEMFD Kconfig is wrapper on both of them. It need not to be visible in menu, So I can make it hidden. WDYT?

Also, KVM VM_FILE preservation and GUEST_MEMFD preservation both depends on LIVEUPDATE_GUEST_MEMFD in this patch series. [PATCH 05/11]* Which is wrong. So I will update KVM VM_FILE preservation to depend only on CONFIG_LIVEUPDATE.

Quoted 21 lines · On Tue, Aug 11, 2026, [email protected] wrote:

Quoted 5 lines · Sean Christopherson

Quoted 4 lines · Tarun Sahu

Introduce the LIVEUPDATE_GUEST_MEMFD Kconfig option. This option enables live update support for KVM guest_memfd files, enabling guest_memfd-backed memory preservation across kernel upgrades.

Quoted 7 lines

Quoted 2 lines

Currently this support only guest_memfd files that are full-shared (INIT_SHARED and no support for private_mem).

Why? Specifically, why do we need/want a separate Kconfig for guest_memfd liveupdate versus KVM liveupdate? I can _maybe_ see a KVM-wide Kconfig, but even that seems like a stretch given that (AFAIK) hypervisors are the one and only use-case for liveupdate.

LIVEUPDATE is used in many subsystem. It is possible to enable liveupdate and kvm without enabling KVM_GUEST_MEMFD. So GUEST_MEMFD preservation must depend on CONFIG_LIVEUPDATE and KVM_GUEST_MEMFD both. LIVEUPDATE_GUEST_MEMFD Kconfig is wrapper on both of them. It need not to be visible in menu, So I can make it hidden. WDYT?

Quoted 4 lines

Also, KVM VM_FILE preservation and GUEST_MEMFD preservation both depends on LIVEUPDATE_GUEST_MEMFD in this patch series. [PATCH 05/11]* Which is wrong. So I will update KVM VM_FILE preservation to depend only on CONFIG_LIVEUPDATE.

Or just handle it all in the makefile? E.g.

kvm/Makefile.kvm +0 -0

index d047d4cf58c9..e6f098498795 100644

- Move ITOA_MAX_LEN to kvm_mm.h for reuse by upcoming kvm_luo code.
- Introduce kvm_create_vm_file() to wrap kvm_create_vm() and anon_inode_getfile(), providing a unified VM file creation API.

[...snip...]

Quoted 4 lines · Tarun Sahu

- Move ITOA_MAX_LEN to kvm_mm.h for reuse by upcoming kvm_luo code.
- Introduce kvm_create_vm_file() to wrap kvm_create_vm() and anon_inode_getfile(), providing a unified VM file creation API.

I think these should be 2 separate patches.

Quoted 4 lines

[...snip...]

- Move ITOA_MAX_LEN to kvm_mm.h for reuse by upcoming kvm_luo code.
- Introduce kvm_create_vm_file() to wrap kvm_create_vm() and anon_inode_getfile(), providing a unified VM file creation API.

Quoted 3 lines · Tarun Sahu

- Move ITOA_MAX_LEN to kvm_mm.h for reuse by upcoming kvm_luo code.
- Introduce kvm_create_vm_file() to wrap kvm_create_vm() and anon_inode_getfile(), providing a unified VM file creation API.

As Ackerley pointed out, changelogs that are literally a list pretty much always needs to be split.

These also need to explain *why*. "providing a unified VM file creation API" isn't sufficient justification. In general, all of these changelogs need to provide more of the "why"; I can figure out what the patches are doing easily enough, but in my speed read of the series, it's hard to figure out the "why".

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch claims to export kvm_uevent_notify_vm_create() but fails to include the EXPORT_SYMBOL_GPL() or EXPORT_SYMBOL_FOR_KVM_INTERNAL() macro. --

--- Patch [3]: [PATCH v4 03/11] KVM: Export kvm_uevent_notify_vm_create() --- commit 5e642ea16f0d267e622a352de60bfe397ecf79df
Author: Tarun Sahu <[email protected]>

KVM: Export kvm_uevent_notify_vm_create()

This commit exposes the kvm_uevent_notify_vm_create function to allow triggering KVM event notifications during VM creation.

[ ... ]

virt/kvm/kvm_main.c static void kvm_uevent_notify_change(unsigned int type, struct kvm *kvm) · line 6354

Quoted 11 lines

virt/kvm/kvm_main.c +4 -0

@@ -6348,6 +6348,11 @@ static void kvm_uevent_notify_change(unsigned int type, struct kvm *kvm)
 	kfree(env);
 }
 
+void kvm_uevent_notify_vm_create(struct kvm *kvm)
+{
+	kvm_uevent_notify_change(KVM_EVENT_CREATE_VM, kvm);
+}

[Severity: Low]
The commit message mentions exporting this function, but is it missing an EXPORT_SYMBOL_GPL or EXPORT_SYMBOL_FOR_KVM_INTERNAL declaration?

Without the macro, won't dynamically loaded architecture-specific modules like kvm-intel.ko hit undefined symbol linking errors when they try to call it?

--
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3

Quoted 27 lines · [email protected] writes:

--- Patch [3]: [PATCH v4 03/11] KVM: Export kvm_uevent_notify_vm_create() --- commit 5e642ea16f0d267e622a352de60bfe397ecf79df
Author: Tarun Sahu <[email protected]>

KVM: Export kvm_uevent_notify_vm_create()

This commit exposes the kvm_uevent_notify_vm_create function to allow triggering KVM event notifications during VM creation.

[ ... ]

virt/kvm/kvm_main.c static void kvm_uevent_notify_change(unsigned int type, struct kvm *kvm) · line 6354

Quoted 11 lines

virt/kvm/kvm_main.c +4 -0

@@ -6348,6 +6348,11 @@ static void kvm_uevent_notify_change(unsigned int type, struct kvm *kvm)
 	kfree(env);
 }
 
+void kvm_uevent_notify_vm_create(struct kvm *kvm)
+{
+	kvm_uevent_notify_change(KVM_EVENT_CREATE_VM, kvm);
+}

[Severity: Low]
The commit message mentions exporting this function, but is it missing an EXPORT_SYMBOL_GPL or EXPORT_SYMBOL_FOR_KVM_INTERNAL declaration?

Quoted 3 lines

Without the macro, won't dynamically loaded architecture-specific modules like kvm-intel.ko hit undefined symbol linking errors when they try to call it?

I'm not 100% sure about the use of EXPORT_SYMBOL... here but usually I compile kvm as a module to try and catch these types of linking issues. Maybe Sean will have a better method/explanation for this.

Quoted 31 lines · [email protected] writes:

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch claims to export kvm_uevent_notify_vm_create() but fails to include the EXPORT_SYMBOL_GPL() or EXPORT_SYMBOL_FOR_KVM_INTERNAL() macro. --

--- Patch [3]: [PATCH v4 03/11] KVM: Export kvm_uevent_notify_vm_create() --- commit 5e642ea16f0d267e622a352de60bfe397ecf79df
Author: Tarun Sahu <[email protected]>

KVM: Export kvm_uevent_notify_vm_create()

This commit exposes the kvm_uevent_notify_vm_create function to allow triggering KVM event notifications during VM creation.

[ ... ]

virt/kvm/kvm_main.c static void kvm_uevent_notify_change(unsigned int type, struct kvm *kvm) · line 6354

Quoted 11 lines

virt/kvm/kvm_main.c +4 -0

@@ -6348,6 +6348,11 @@ static void kvm_uevent_notify_change(unsigned int type, struct kvm *kvm)
 	kfree(env);
 }
 
+void kvm_uevent_notify_vm_create(struct kvm *kvm)
+{
+	kvm_uevent_notify_change(KVM_EVENT_CREATE_VM, kvm);
+}

[Severity: Low]
The commit message mentions exporting this function, but is it missing an EXPORT_SYMBOL_GPL or EXPORT_SYMBOL_FOR_KVM_INTERNAL declaration?

Quoted 4 lines

Without the macro, won't dynamically loaded architecture-specific modules like kvm-intel.ko hit undefined symbol linking errors when they try to call it?

I'm not 100% sure about the use of EXPORT_SYMBOL... here but usually I compile kvm as a module to try and catch these types of linking issues. Maybe Sean will have a better method/explanation for this.

This brings about another question I have though. How does luo work if the new kernel's deserialization of the persisted data structures depends on a module? Like in this case, KVM is a module, if KVM isn't loaded in the new kernel, do the data structures stick around until KVM is loaded? Or is KVM required to be loaded as a module in the new kernel?

Quoted 3 lines

--
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3

- Add a weak reference 'vm_file' in struct kvm under

Quoted 1 line · Tarun Sahu

- Add a weak reference 'vm_file' in struct kvm under

"vm_file" is effectively already claimed by vm_area_struct.vm_file. *If* we go this route, I would very strongly prefer to take a dependency on "vfio: Use file-based reference counting for KVM"[*]. I'll poke that thread, we really should land that one particular patch long before the s390-is-arm64 insanity.

Empashish on "if" because this all feels backwards.

It's not at all clear to
me why liveupdate goes directly to guest_memfd, but then requires a token associated with the VM.

https://lore.kernel.org/all/[email protected]

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.

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.

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

MAINTAINERS +0 -0

index a3ed337e827d..0283f0fd6ef4 100644
@@ -14539,6 +14539,17 @@ S:	Maintained
 F:	Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
 F:	drivers/video/backlight/ktz8866.c

MAINTAINERS +2 -0

+F:	virt/kvm/kvm_luo.c
+
 KVM PARAVIRT (KVM/paravirt)
 M:	Paolo Bonzini <[email protected]>
 R:	Vitaly Kuznetsov <[email protected]>

include/linux/kho/abi/kvm.h new file +39 -0

new file mode 100644
index 000000000000..718db68a541a
@@ -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 */

virt/kvm/Makefile.kvm +1 -0

index d047d4cf58c9..c1a962159264 100644
@@ -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

virt/kvm/kvm_luo.c new file +12 -0

new file mode 100644
index 000000000000..025b53151b6a
@@ -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
+ *

virt/kvm/kvm_luo.c new file +11 -0

+ * 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
+ * ========================

virt/kvm/kvm_luo.c new file +8 -0

+
+	if (kvm->vm_dead || kvm->vm_bugged)
+		return -EINVAL;
+
+	ser = kho_alloc_preserve(sizeof(*ser));
+	if (IS_ERR(ser))
+		return PTR_ERR(ser);
+

virt/kvm/kvm_luo.c new file +9 -0

+
+	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)
+{

Quoted 5 lines · Tarun Sahu

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?

Quoted 6 lines

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.

Quoted 3 lines

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.

Quoted 23 lines

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

MAINTAINERS +0 -0

index a3ed337e827d..0283f0fd6ef4 100644
@@ -14539,6 +14539,17 @@ S:	Maintained
 F:	Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
 F:	drivers/video/backlight/ktz8866.c

MAINTAINERS S: Maintained · line 14550

Quoted 10 lines

MAINTAINERS +9 -0

 
+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.

Quoted 6 lines

MAINTAINERS +2 -0

+F:	virt/kvm/kvm_luo.c
+
 KVM PARAVIRT (KVM/paravirt)
 M:	Paolo Bonzini <[email protected]>
 R:	Vitaly Kuznetsov <[email protected]>

Quoted 19 lines · Sean Christopherson

Quoted 5 lines · Tarun Sahu

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?

Quoted 9 lines

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.

Quoted 4 lines

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.

You _can_ preserve vCPUs today using KVM_{GET,SET}_REGS, they just won't run in the background during the reboot.

This series can save you from dumping VM memory to disk if it is backed by guest_memfd.

Quoted 15 lines

Review

Quoted 9 lines

(quoted diff) +9 -0

+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

Quoted 3 lines

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.

I think it is fine if you want to take these changes through the KVM tree, but I would like live update maintainers to be listed as reviewers at least.

At the same time, I also keep being (pleasantly)
surprised at preservation being relatively simple. For example, the code to preserve a shmem file (via memfd) is roughly 600 lines, a big chunk of which is comments. The code of course has some limitations, but it is good enough for use in production.

For one, we care about ABI breakages and versioning.

The serialized state is a part of live update ABI and changes to it should be ACKed by us.

For another, how the file handlers interact with their dependencies can affect the behaviour that VMMs observe. Those changes should also pass by some live update eyes.

Quoted 26 lines · Pratyush Yadav

Quoted 23 lines · Sean Christopherson

Quoted 5 lines · Tarun Sahu

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?

Quoted 9 lines

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.

Quoted 2 lines

You _can_ preserve vCPUs today using KVM_{GET,SET}_REGS, they just won't run in the background during the reboot.

What about x86 CoCo VMs? Which are quite literally _the_ reason guest_memfd was created in the first place.

Quoted 3 lines

This series can save you from dumping VM memory to disk if it is backed by guest_memfd.

Or to word it another way, one _can_ save guest_memfd, it's just slower. My

point is that this series needs to provide a _lot_ more information about the bigger KVM picture. For those of us that are on the very fringes of live update, it's practically impossible to review because, to us, it seems very arbitrary.

The part that's especially confusing is the saving of the VM type. That comes straight from userspace, so it's super bizarre to automatically save/restore that, but nothing else.

Quoted 15 lines

Quoted 15 lines

Review

Quoted 9 lines

(quoted diff) +9 -0

+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

...

Quoted 7 lines

Quoted 3 lines

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.

I think it is fine if you want to take these changes through the KVM tree, but I would like live update maintainers to be listed as reviewers at least.

Why not simply add a file pattern match to the LIVE UPDATE entry?

MAINTAINERS +0 -0

index 8014b9f8253e..2eb57b22c37f 100644

Quoted 8 lines

At the same time, I also keep being (pleasantly)
surprised at preservation being relatively simple. For example, the code to preserve a shmem file (via memfd) is roughly 600 lines, a big chunk of which is comments. The code of course has some limitations, but it is good enough for use in production.

For one, we care about ABI breakages and versioning.

Which is amusing to me because that implies KVM does not, and I would hazard to

guess that KVM has the biggest ABI surface of any subsystem in the kernel by a country mile (though I'm probably wildly underestimating the effective ABI surface of filesystems).

Quoted 2 lines

The serialized state is a part of live update ABI and changes to it should be ACKed by us.

Meh, "Don't break userspace" is a universal rule in the kernel, I genuinely don't see why liveupdate needs special treatment.

Quoted 4 lines

For another, how the file handlers interact with their dependencies can affect the behaviour that VMMs observe. Those changes should also pass by some live update eyes.

Perhaps in the short term, but IMO, that's not a winning strategy in the long term. From my perspective, that like saying the PAGE CACHE maintainers should review every usage of the filemap APIs, because how the APIs are used impacts the page cache and affects userspace-visible behavior. There are myriad analogies like that throughout the kernel.

Yes, liveupdate is new and shiny, but IMO for it to be successful and maintainable, it needs to be treated like any other core infrastructure in the kernel, not a special snowflake whose details are known only by a handful of people. Because I think it's likely liveupdate goes one of two ways: either liveupdate becomes a very niche thing that is used sparingly throughout the kernel, or it becomes a broadly used feature that is supported by many filesystems and subsystems.

If liveupdate is relegated to niche status, then it probably isn't going to see a significant amount of ongoing development, at which point the folks working on liveupdate will naturally migrate to other projects, and maintenance will largely be left to subsystem maintainers.

If liveupdate is broadly used, then having a single group of people maintain every subsystem's usage won't scale, and maintenance will again largely fall on the shoulder of subsystem maintainers. Which is totally fine and working as intended, because that's exactly what subystem maintainers are signing up for by merging support for liveupdate.

Quoted 30 lines · Sean Christopherson

Quoted 28 lines · Pratyush Yadav

Quoted 15 lines · Sean Christopherson

Quoted 5 lines · Tarun Sahu

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?

Quoted 6 lines

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.

Quoted 8 lines

Quoted 3 lines

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.

You _can_ preserve vCPUs today using KVM_{GET,SET}_REGS, they just won't run in the background during the reboot.

Quoted 2 lines

What about x86 CoCo VMs? Which are quite literally _the_ reason guest_memfd was created in the first place.

I don't know much about the history but I thought these days guest_memfd is used for more than just encrypted memory. I have seen talk of it being used for non-confidential VMs. For example these patches [0][1][2].

The CoCo parts can follow, but IIUC guest_memfd is being used to back guest memory on non-CoCo VMs too.

Quoted 22 lines

Quoted 7 lines

Quoted 3 lines

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.

I think it is fine if you want to take these changes through the KVM tree, but I would like live update maintainers to be listed as reviewers at least.

Why not simply add a file pattern match to the LIVE UPDATE entry?

MAINTAINERS +1 -1

index 8014b9f8253e..2eb57b22c37f 100644
@@ -15052,8 +15052,8 @@ F:      include/linux/liveupdate.h
 F:     include/uapi/linux/liveupdate.h
 F:     kernel/liveupdate/
 F:     lib/tests/liveupdate.c
-F:     mm/memfd_luo.c
 F:     tools/testing/selftests/liveupdate/
+N:     [^a-z]luo
 

MAINTAINERS F: include/linux/liveupdate.h · line 15059

Quoted 2 lines

MAINTAINERS +0 -0

 LLC (802.2)
 L:     [email protected]

This would list us as maintainers of kvm_luo.c and the tree as liveupdate.git,

both of which is something you're saying you _don't_ want.

Quoted 9 lines

Quoted 7 lines

At the same time, I also keep being (pleasantly)
surprised at preservation being relatively simple. For example, the code to preserve a shmem file (via memfd) is roughly 600 lines, a big chunk of which is comments. The code of course has some limitations, but it is good enough for use in production.

For one, we care about ABI breakages and versioning.

Which is amusing to me because that implies KVM does not, and I would hazard to

No, it doesn't. What I'm saying is I care about changes to the _live update ABI_. Just like you probably care about changes to KVM ABI but not so much about BPF for example.

Quoted 7 lines

guess that KVM has the biggest ABI surface of any subsystem in the kernel by a country mile (though I'm probably wildly underestimating the effective ABI surface of filesystems).

Quoted 2 lines

The serialized state is a part of live update ABI and changes to it should be ACKed by us.

Quoted 2 lines

Meh, "Don't break userspace" is a universal rule in the kernel, I genuinely don't see why liveupdate needs special treatment.

Ironically enough, you miss my point. I'm not talking about userspace ABI. We all know not to break that. I am talking about live update _serialization ABI_. See the stuff under include/linux/kho/abi. This series also adds things there.

This is ABI between kernels. It needs to be stable-ish so you can move from one kernel version to another. At the same time, unlike userspace ABI, it can change.

Today we don't have any rules and let you change things freely as long as you do a version bump. But at a later point, the plan is to add some stability requirements to the ABI so you can actually upgrade the kernel across major versions.

So at least for ABI changes, there should be an explicit ACK from the live update group.

Quoted 1 line · Pratyush Yadav

On Tue, Aug 11 2026, Sean Christopherson wrote:

But that's all beside the point. What I'm saying is that SNP and TDX *must* use guest_memfd, whereas guest_memfd is optional for all other VM types. And so adding LUO support for guest_memfd without even sketching out a plan for CoCo VMs feels backwards.

I'm not necessarily opposed to gradual guest_memfd support, but there needs to be a clear plan of how all of this is going to fit together. It doesn't need to be perfect, and I'm sure we'll make mistakes along the way, but I want to at least try not to paint ourselves into a corner, especially with respect to the ABI.

Quoted 23 lines

Quoted 23 lines

Quoted 8 lines

Quoted 4 lines

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.

I think it is fine if you want to take these changes through the KVM tree, but I would like live update maintainers to be listed as reviewers at least.

Why not simply add a file pattern match to the LIVE UPDATE entry?

MAINTAINERS +1 -1

index 8014b9f8253e..2eb57b22c37f 100644
@@ -15052,8 +15052,8 @@ F:      include/linux/liveupdate.h
 F:     include/uapi/linux/liveupdate.h
 F:     kernel/liveupdate/
 F:     lib/tests/liveupdate.c
-F:     mm/memfd_luo.c
 F:     tools/testing/selftests/liveupdate/
+N:     [^a-z]luo
 

Quoted 4 lines

MAINTAINERS F: include/linux/liveupdate.h · line 15059

Quoted 2 lines

MAINTAINERS +0 -0

 LLC (802.2)
 L:     [email protected]

This would list us as maintainers of kvm_luo.c and the tree as liveupdate.git,

It would list both "LIVE UPDATE" and "KERNEL VIRTUAL MACHINE (KVM)", as KVM would
still cover the files via "F: virt/kvm/*". And my read of MAINTAINERS is that
N: and K: entries are "secondary" if the files/scope is covered by an F: entry.

E.g. arch/x86/kvm/vmx/tdx.c is covered by "KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)"
via "F: arch/x86/kvm/*/", and also by "X86 TRUST DOMAIN EXTENSIONS (TDX)" via
"N: tdx" (or maybe "K: \b(tdx)"? I haven't bothered to check which one
triggers). And while I don't think there was ever any formal discussion, AFAIK everyone reads the situation as KVM still being the primary maintainer/tree for that code.

Quoted 1 line

both of which is something you're saying you _don't_ want.

No, what I don't want is a dedicated "KVM LIVE UPDATE" entry, because I think most
people would read "F: virt/kvm/kvm_luo.c" and "F: virt/kvm/guest_memfd_luo.c"
as being more precise than KVM's "F: virt/kvm/*" and thus would read things as
"KVM LIVE UPDATE" being the primary maintainer.

In other words, I'm more than ok with LUO being looped in on KVM LUO changes and having the authority to object to problematic changes, but I'm not ok with LUO taking primary ownership of KVM code.

I realize there's more than a bit of nuance in my interpretation of N: and K:, but again my experience with TDX is that so long as the maintainers are aligned on expectations, it's a non-issue in practice.

Quoted 22 lines

Quoted 10 lines

Quoted 8 lines

At the same time, I also keep being (pleasantly)
surprised at preservation being relatively simple. For example, the code to preserve a shmem file (via memfd) is roughly 600 lines, a big chunk of which is comments. The code of course has some limitations, but it is good enough for use in production.

For one, we care about ABI breakages and versioning.

Which is amusing to me because that implies KVM does not, and I would hazard to

No, it doesn't. What I'm saying is I care about changes to the _live update ABI_. Just like you probably care about changes to KVM ABI but not so much about BPF for example.

Quoted 7 lines

guess that KVM has the biggest ABI surface of any subsystem in the kernel by a country mile (though I'm probably wildly underestimating the effective ABI surface of filesystems).

Quoted 2 lines

The serialized state is a part of live update ABI and changes to it should be ACKed by us.

Quoted 7 lines

Quoted 2 lines

Meh, "Don't break userspace" is a universal rule in the kernel, I genuinely don't see why liveupdate needs special treatment.

Ironically enough, you miss my point. I'm not talking about userspace ABI. We all know not to break that. I am talking about live update _serialization ABI_. See the stuff under include/linux/kho/abi. This series also adds things there.

No, I understand exactly what ABI you're talking about.

Quoted 3 lines

This is ABI between kernels. It needs to be stable-ish so you can move from one kernel version to another. At the same time, unlike userspace ABI, it can change.

Uh, yeah, so KVM has been managing such immutable ABI for practically its entire existence. KVM's save/restore uAPI has exactly what you're describing: serialization ABI that needs to be backwards and forwards compatible between different kernels in order to support both upgrade and rollback scenarios via live migration.

KVM also has immutable ABI between itself and guest kernels, including implicit "ABI" in the form of not changing guest-visible behavior.

Quoted 7 lines

Today we don't have any rules and let you change things freely as long as you do a version bump. But at a later point, the plan is to add some stability requirements to the ABI so you can actually upgrade the kernel across major versions.

So at least for ABI changes, there should be an explicit ACK from the live update group.

I don't entirely agree. I get where you're coming from, and I 100% agree that the more eyeballs on changes that may affect ABI, the better.

Where I have problems with the above is that it doesn't account for the nuances of save/restore across different kernels. The literal format of the serialized data is the most obvious form of ABI, but it's absolutely possible to change ABI without changing the data format.

E.g. say there's a flags field in some serialization structure, and flags X and Y are mutually exclusive in current kernels. If a future kernel relaxes that restriction for whatever reason, then the effective ABI has been broken because state created and saved on new kernels can't be restored on old kernels. And this is not a theoretical concern, KVM has run afoul of this a few times (though thankfully very rarely).

I don't think it's reasonable to expect LUO maintainers to gain enough expertise in each subsystem to be able to ensure changes are forwards and backwards compatible. The only way I see LUO being successful in the long term is to get subsystem maintainers/contributors to understand *and buy-in* to the LUO model and rules, so that each subsystem can largely be self-sustatining. I.e. setting yourselves up as literal gatekeepers will help prevent blatant breakage, but it's less likely to help guard against more subtle breakage, and in my experience, subtle breakage is by far harder to detect and more painful to deal with.

Somewhat of a side topic: in my experience, using monotonically increasing version numbers is a horrible way to enumerate features/content. So for me, allowing KVM's LUO ABI to change with a verson bump is probably a non-starter. I.e. whatever gets merged needs to be more future-proof than "we'll deal with it later".

Quoted 9 lines · Sean Christopherson

Quoted 3 lines · Pratyush Yadav

This is ABI between kernels. It needs to be stable-ish so you can move from one kernel version to another. At the same time, unlike userspace ABI, it can change.

Uh, yeah, so KVM has been managing such immutable ABI for practically its entire existence. KVM's save/restore uAPI has exactly what you're describing: serialization ABI that needs to be backwards and forwards compatible between different kernels in order to support both upgrade and rollback scenarios via live migration.

I think there is a slight difference between KVM's save/resture uAPI and live update's ABI. With KVM's uAPI, you need to maintain strict backwards compatibility because userspace reads what you output. So if you change the layout, userspace will interpret it wrong and might break.

With live update, the ABI never gets to userspace. It is used to talk between kernels directly. So if you do break that, your userspace keeps working fine, you just might not be able to live update to the incompatible kernel.

So with live update, we don't need to keep backwards compatibility in the ABI forever. Of course, it is good to minimize changes, but we have more freedom to change it.

Quoted 17 lines · Pratyush Yadav

Quoted 9 lines · Sean Christopherson

Quoted 3 lines · Pratyush Yadav

This is ABI between kernels. It needs to be stable-ish so you can move from one kernel version to another. At the same time, unlike userspace ABI, it can change.

Uh, yeah, so KVM has been managing such immutable ABI for practically its entire existence. KVM's save/restore uAPI has exactly what you're describing: serialization ABI that needs to be backwards and forwards compatible between different kernels in order to support both upgrade and rollback scenarios via live migration.

I think there is a slight difference between KVM's save/resture uAPI and live update's ABI. With KVM's uAPI, you need to maintain strict backwards compatibility because userspace reads what you output. So if you change the layout, userspace will interpret it wrong and might break.

Quoted 8 lines

With live update, the ABI never gets to userspace. It is used to talk between kernels directly. So if you do break that, your userspace keeps working fine, you just might not be able to live update to the incompatible kernel.

So with live update, we don't need to keep backwards compatibility in the ABI forever. Of course, it is good to minimize changes, but we have more freedom to change it.

Ah. So this is the heart of the disconnect. I very strongly disagree with the statement that live update doesn't need to support backwards compatibility. I can totally believe that the folks working on live update are ok breaking backwards compatibility because their use cases are "fine" with such breakage. And I can also believe live update as an upstream kernel feature being developed by those same folks is also ok with breaking backwards compatibility.

But with my upstream KVM maintainer hat on, I am not ok with that. I did not agree to support a world where KVM is allowed to break backwards compatibility, so long as it's done "carefully" or whatever. If y'all want to deal with the resulting complexity, that's fine by me, but you'll be doing it without KVM.

I totally understand that exploratory work and initial development is best done in private and/or in a small working groups. But decisions that will significantly impact multiple subsystems need to be made *with* those subystems. I mean, obviously it's possible to make a decision in a small group and then "publish" the result later, but then as is happening here, the community and subsystem maintainers like me may refuse to play ball if they disagree.

Hi Sean,

Quoted 14 lines · Sean Christopherson

Quoted 5 lines · Pratyush Yadav

Quoted 1 line · Sean Christopherson

On Wed, Aug 12, 2026, Pratyush Yadav wrote:

So with live update, we don't need to keep backwards compatibility in the ABI forever. Of course, it is good to minimize changes, but we have more freedom to change it.

Ah. So this is the heart of the disconnect. I very strongly disagree with the statement that live update doesn't need to support backwards compatibility. I can totally believe that the folks working on live update are ok breaking backwards compatibility because their use cases are "fine" with such breakage. And I can also believe live update as an upstream kernel feature being developed by those same folks is also ok with breaking backwards compatibility.

Quoted 4 lines

But with my upstream KVM maintainer hat on, I am not ok with that. I did not agree to support a world where KVM is allowed to break backwards compatibility, so long as it's done "carefully" or whatever. If y'all want to deal with the resulting complexity, that's fine by me, but you'll be doing it without KVM.

Let's step back a bit. I don't think backwards compatibility in the _ABI_ is all that important in live update's context. What is important is that our users are able to live update from kernel version X to Y. The line format the kernel uses to describe its state is an implementation detail. Our users never see it.

The high level idea is that when you need to make a change to the ABI so the kernel can better describe the objects/resources/files it is passing, you create a new version of the ABI and allow transitions from older versions.

Say you make some changes and need an ABI version v5. You don't get rid of v4. You keep it around. LUO core will facilitate picking the right version for the next kernel. So it will be possible to seamlessly upgrade your kernel that speaks v4 to a new kernel that speaks v4 and v5. Now this kernel can start speaking v5 if its successor speaks v5 too. And so on for going to v6 and v7, etc.

After a "reasonable" time given for upgrades, you deprecate v4. v4 has been around long enough and our users have had a chance to go to kernels speaking newer versions. That's when you remove the code for v4 from the kernel.

We can argue what "reasonable" means, but the core idea stays.

It will still be possible to go back to v4 or earlier, but you'd need an extra stop along the way. And of course, vendors can keep a wider support matrix downstream if they see the need for it.

Does this idea of "backwards compatibility" sound acceptable to you, at least at a high level?

Quoted 23 lines · Pratyush Yadav

Hi Sean,

Quoted 14 lines · Sean Christopherson

Quoted 5 lines · Pratyush Yadav

Quoted 1 line · Sean Christopherson

On Wed, Aug 12, 2026, Pratyush Yadav wrote:

So with live update, we don't need to keep backwards compatibility in the ABI forever. Of course, it is good to minimize changes, but we have more freedom to change it.

Ah. So this is the heart of the disconnect. I very strongly disagree with the statement that live update doesn't need to support backwards compatibility. I can totally believe that the folks working on live update are ok breaking backwards compatibility because their use cases are "fine" with such breakage. And I can also believe live update as an upstream kernel feature being developed by those same folks is also ok with breaking backwards compatibility.

Quoted 4 lines

But with my upstream KVM maintainer hat on, I am not ok with that. I did not agree to support a world where KVM is allowed to break backwards compatibility, so long as it's done "carefully" or whatever. If y'all want to deal with the resulting complexity, that's fine by me, but you'll be doing it without KVM.

Quoted 5 lines

Let's step back a bit. I don't think backwards compatibility in the _ABI_ is all that important in live update's context. What is important is that our users are able to live update from kernel version X to Y. The line format the kernel uses to describe its state is an implementation detail. Our users never see it.

The rule is thou shalt not break userspace. Whether or not the breakage is the result of an explicit ABI change is irrelevant.

Quoted 17 lines

The high level idea is that when you need to make a change to the ABI so the kernel can better describe the objects/resources/files it is passing, you create a new version of the ABI and allow transitions from older versions.

Say you make some changes and need an ABI version v5. You don't get rid of v4. You keep it around. LUO core will facilitate picking the right version for the next kernel. So it will be possible to seamlessly upgrade your kernel that speaks v4 to a new kernel that speaks v4 and v5. Now this kernel can start speaking v5 if its successor speaks v5 too. And so on for going to v6 and v7, etc.

After a "reasonable" time given for upgrades, you deprecate v4. v4 has been around long enough and our users have had a chance to go to kernels speaking newer versions. That's when you remove the code for v4 from the kernel.

Quoted 8 lines

We can argue what "reasonable" means, but the core idea stays.

It will still be possible to go back to v4 or earlier, but you'd need an extra stop along the way. And of course, vendors can keep a wider support matrix downstream if they see the need for it.

Does this idea of "backwards compatibility" sound acceptable to you, at least at a high level?

No.

It's probably fine for Google and other large companies that tightly control their kernels and use cases, and have the resources to juggle the resulting complexity, e.g. have kernel engineers on staff to track feature and dependencies, coordinate and plan kernel upgrades, etc.

It's not acceptable for upstream, where downstream consumers often run a distro kernel, have much more varied use cases, and don't always have a horde of kernel engineers on staff to help them thread the needle you describe above. And if supporting live update as a general feature for all users of the kernel isn't being factored into design considerations, then that needs to change, otherwise this is all dead in the water.

I also don't see the point. Maintaining a rigid save/restore ABI is annoying, but it's not _hard_ (or at least, not _that_ hard), especially if there's a set of well-documented best known practices that subsystems can follow, e.g. so that individual subsystems don't need to learn painful lessons first-hand. I genuinely believe that maintaining the version hell you describe above would be more costly in the long run than simply committing to full backwards compatibility within a given subsystem. I can imagine that enumerating what subsystems' information is in the payload will require a different scheme, but for a given subsystem, I don't see any reason to aim for anything less than full backwards compatibility.

Hi Sean,

Quoted 17 lines · Sean Christopherson

Quoted 2 lines

Does this idea of "backwards compatibility" sound acceptable to you, at least at a high level?

No.

It's probably fine for Google and other large companies that tightly control their kernels and use cases, and have the resources to juggle the resulting complexity, e.g. have kernel engineers on staff to track feature and dependencies, coordinate and plan kernel upgrades, etc.

It's not acceptable for upstream, where downstream consumers often run a distro kernel, have much more varied use cases, and don't always have a horde of kernel engineers on staff to help them thread the needle you describe above. And if supporting live update as a general feature for all users of the kernel isn't being factored into design considerations, then that needs to change, otherwise this is all dead in the water.

Quoted 9 lines

I also don't see the point. Maintaining a rigid save/restore ABI is annoying, but it's not _hard_ (or at least, not _that_ hard), especially if there's a set of well-documented best known practices that subsystems can follow, e.g. so that individual subsystems don't need to learn painful lessons first-hand. I genuinely believe that maintaining the version hell you describe above would be more costly in the long run than simply committing to full backwards compatibility within a given subsystem. I can imagine that enumerating what subsystems' information is in the payload will require a different scheme, but for a given subsystem, I don't see any reason to aim for anything less than full backwards compatibility.

Let's say for argument's sake that we commit for a fully stable backwards compatible ABI. Even then, you have to deal with multiple ABI versions.

Live update's ABI is more complex compared to KVM's save/restore ABI. For the KVM save/restore uAPI, you are largely describing architectural state like CPU registers, etc. These things don't evolve as fast and more or less stay the same.

Live update needs to describe the state of kernel objects. These are more complex

and evolve faster.

For example, say you merge guest_memfd preservation today. Some time later, someone comes up with a more efficient data structure to track the folios in the file. You _have_ to make a backwards-incompatible ABI change to use this data structure.

Or say you add a new memory backend (like the HugeTLB patches in flight). That likely will need a different ABI to describe the state of the guest_memfd.

So you will end up with multiple ABI versions that aren't always backwards compatible.

If you refuse that idea too, then KVM live update will be dead in the water for a different reason. It will be damn near useless because it can't keep up with an evolving subsystem.

Now once you get multiple ABI versions and you can seamlessly go from old to new one, say you have a version that was superseded 5 years ago. It would be completely reasonable to say that this version is old enough and no one should be going from a 5 year old kernel to a modern one.

So you deprecate this ABI. Deprecating old unused uAPIs is not unprecedented.

I think we are better off formalizing this deprecation period from the get go.

A somewhat tangential example is BPF kfuncs. My BPF program that works in kernel X might not work in kernel Y because the kfunc has changed or been removed.

The argument they make in kfuncs.rst is that kfuncs "provide a kernel <-> kernel API, and thus are not bound by any of the strict stability restrictions associated with kernel <-> user UAPIs".

For LUO as well, this is a kernel -> kernel API.

Users can also still do a regular kexec or reboot. They just won't get the performance optimization of LUO.

Regardless of if you agree with the last bit about deprecating old versions, ABIs evolving with the subsystem is a ground reality of live update and it would be foolish to think we can do with only backwards-compatible ABI changes forever.

Quoted 30 lines · Pratyush Yadav

Hi Sean,

Quoted 17 lines · Sean Christopherson

Quoted 2 lines

Does this idea of "backwards compatibility" sound acceptable to you, at least at a high level?

No.

It's probably fine for Google and other large companies that tightly control their kernels and use cases, and have the resources to juggle the resulting complexity, e.g. have kernel engineers on staff to track feature and dependencies, coordinate and plan kernel upgrades, etc.

It's not acceptable for upstream, where downstream consumers often run a distro kernel, have much more varied use cases, and don't always have a horde of kernel engineers on staff to help them thread the needle you describe above. And if supporting live update as a general feature for all users of the kernel isn't being factored into design considerations, then that needs to change, otherwise this is all dead in the water.

Quoted 9 lines

I also don't see the point. Maintaining a rigid save/restore ABI is annoying, but it's not _hard_ (or at least, not _that_ hard), especially if there's a set of well-documented best known practices that subsystems can follow, e.g. so that individual subsystems don't need to learn painful lessons first-hand. I genuinely believe that maintaining the version hell you describe above would be more costly in the long run than simply committing to full backwards compatibility within a given subsystem. I can imagine that enumerating what subsystems' information is in the payload will require a different scheme, but for a given subsystem, I don't see any reason to aim for anything less than full backwards compatibility.

Quoted 8 lines

Let's say for argument's sake that we commit for a fully stable backwards compatible ABI. Even then, you have to deal with multiple ABI versions.

Live update's ABI is more complex compared to KVM's save/restore ABI. For the KVM save/restore uAPI, you are largely describing architectural state like CPU registers, etc. These things don't evolve as fast and more or less stay the same.

Right, because nothing meaningful has changed in any architecture in the 20+ years since KVM has provided save/restore support, whereas guest_memfd looks nothing like it did when it was introduced three years ago.

Quoted 2 lines

Live update needs to describe the state of kernel objects. These are more complex

LOL, you might be the first to claim x86 virtualization isn't all that complex.

Quoted 1 line

and evolve faster.

The speed at which things change doesn't automatically mean we shouldn't strive for backwards compatibility. Yes, providing backwards compatibility requires additional care and planning, and over time *might* lead to an ABI that is difficult to maintain. But IMO, that just makes it all the more important to get the design right the first time, not that we shouldn't even try because it's hard.

Quoted 4 lines

For example, say you merge guest_memfd preservation today. Some time later, someone comes up with a more efficient data structure to track the folios in the file. You _have_ to make a backwards-incompatible ABI change to use this data structure.

Only if those details bleed into the ABI/contract. I actually have a concrete KVM (well, virtualization) example for this.

Intel's VMX architecture disallows direct memory accesses to the VMCS, and instead requires software to access the VMCS via dedicated ISA, using architectural encoding numbers to reference VMCS fields. I.e. VMX decouples how data is stored in memory (the data structures) from the ABI/contract with software (VMCS field encodings).

This allows Intel to optimize the data structures to be more efficient and performant for each microarchitecture based on the features and properties of each uarch, all without breaking backwards/forwards compatibility with software.

My favorite esoteric example is AR_BYTES packing. For Haswell, Intel added an optimization in ucode to allow saving/loading segment register state in a single uop (IIRC). The optimization was especially valuable for virtualization as it shaved cycles off the VM-Enter/VM-Exit hot paths. A key piece of the optimization was it required the AR_BYTES metadata to be stored in 16 bits, but existing CPUs stored AR_BYTES using 32 bits in an "unpacked" format.

Fortunately, because the in-memory representation was decoupled from the contract with software, Intel could pack AR_BYTES into 16 bits for Haswell+ and pack/unpack the data on VMWRITE/VMREAD, so that the format presented to software remained unchanged.

Does VMX's decoupling of the in-memory represntation of a VMCS have downsides? Absolutely. Most notably, it incurs extra complexity (in software and hardware) to achieve comparable performance to directly accessible data structures (AMD's VMCB and Hyper-V's eVMCS) for nested virtualization. And I'm sure it has placed contraints on Intel's designs, and obviously introduces complexity into the overall system by adding a layer of indirection. But IMO the VMX architecture has been a huge win overall for Intel.

Quoted 6 lines

Or say you add a new memory backend (like the HugeTLB patches in flight). That likely will need a different ABI to describe the state of the guest_memfd.

So you will end up with multiple ABI versions that aren't always backwards compatible.

No, you end up with *features* that aren't backwards compatible. I can't imagine anyone will argue that we should never add new features because then we can't rollback to an older kernel.

But adding a new feature shouldn't break the existing ABI. E.g. adding support for HugeTLB in guest_memfd shouldn't prevent rolling back to an older kernel when the HugeTLB functionality isn't being used.

Using AMD's VMCB and Intel's VMCS as examples, literally every major new AMD/Intel uarch extends the VMC{B,S} in some way, but without fail it's always done in a way that is backwards compatible with existing software. I.e. AMD and Intel ship new features, but existing software continues to work, and VMs continue to be migratable across CPU generations[*], with the obvious restriction that migrating a VM using a feature introduced on generation N to a generation N-1 CPU isn't a smart idea.

[*] There are exceptions. E.g. Intel removed MPX, and so VMs with MPX can't be
migrated to newer CPUs. Migrating between CPUs with different MAXPHYADDR is sketchy (and simply not done by some CSPs) because neither AMD nor Intel virtualizes MAXPHYADDR. But those exceptions are absolutely Big Deals that undergo significant scrutiny, from all parties involved.

Quoted 8 lines

If you refuse that idea too, then KVM live update will be dead in the water for a different reason. It will be damn near useless because it can't keep up with an evolving subsystem.

Now once you get multiple ABI versions and you can seamlessly go from old to new one, say you have a version that was superseded 5 years ago. It would be completely reasonable to say that this version is old enough and no one should be going from a 5 year old kernel to a modern one.

LOL, Google literally does this. Granted, the extreme cases only happen for stragglers, and I think we do force VMs to bounce through a "middle" kernel in those cases, but I doubt Google is the only company that runs frankenkernels for an absurd number of years for a variety of reasons. E.g. 4.4 LTS was officially supported for 6 years, and I'll bet dollars to donuts people ran it for much longer than that.

Quoted 1 line

So you deprecate this ABI. Deprecating old unused uAPIs is not unprecedented.

When there are provably no users, or we can convince existing userspace to migrate to an alternative.

Quoted 2 lines

I think we are better off formalizing this deprecation period from the get go.

Why? What does it buy us? Because all I see is potential abuse and an excuse for not spending time getting the designs right.

Quoted 7 lines

A somewhat tangential example is BPF kfuncs. My BPF program that works in kernel X might not work in kernel Y because the kfunc has changed or been removed.

The argument they make in kfuncs.rst is that kfuncs "provide a kernel <-> kernel API, and thus are not bound by any of the strict stability restrictions associated with kernel <-> user UAPIs".

BPF's documentation isn't arguing anything, it's merely reiterating Linux's long-standing policy that there is no such thing as a stable kernel ABI (in upstream).

Quoted 1 line

For LUO as well, this is a kernel -> kernel API.

Stating the obvious, I disagree with this. As I said before, if this is the stance LUO wants to take, then so be it, but my NAK stands.

Quoted 2 lines

Users can also still do a regular kexec or reboot. They just won't get the performance optimization of LUO.

The amount of time, energy, and money poured into minimizing VM downtime on live migration suggests the overwhelming majority of LUO's targeted users aren't going to take kindly to this stance.

Quoted 4 lines

Regardless of if you agree with the last bit about deprecating old versions, ABIs evolving with the subsystem is a ground reality of live update and it would be foolish to think we can do with only backwards-compatible ABI changes forever.

I never said the ABI is immutable, I said it needs to be backwards/forwards compatible.

Quoted 23 lines · Pratyush Yadav

Hi Sean,

Quoted 18 lines · Sean Christopherson

Quoted 5 lines · Pratyush Yadav

Quoted 1 line · Sean Christopherson

On Wed, Aug 12, 2026, Pratyush Yadav wrote:

So with live update, we don't need to keep backwards compatibility in the ABI forever. Of course, it is good to minimize changes, but we have more freedom to change it.

Ah. So this is the heart of the disconnect. I very strongly disagree with the statement that live update doesn't need to support backwards compatibility. I can totally believe that the folks working on live update are ok breaking backwards compatibility because their use cases are "fine" with such breakage. And I can also believe live update as an upstream kernel feature being developed by those same folks is also ok with breaking backwards compatibility.

But with my upstream KVM maintainer hat on, I am not ok with that. I did not agree to support a world where KVM is allowed to break backwards compatibility, so long as it's done "carefully" or whatever. If y'all want to deal with the resulting complexity, that's fine by me, but you'll be doing it without KVM.

Quoted 5 lines

Let's step back a bit. I don't think backwards compatibility in the _ABI_ is all that important in live update's context. What is important is that our users are able to live update from kernel version X to Y. The line format the kernel uses to describe its state is an implementation detail. Our users never see it.

The rule is thou shalt not break userspace. Whether or not the breakage is the result of an explicit ABI change is irrelevant.

It's probably fine for Google and other large companies that tightly control their kernels and use cases, and have the resources to juggle the resulting complexity, e.g. have kernel engineers on staff to track feature and dependencies, coordinate and plan kernel upgrades, etc.

engineers on staff to help them thread the needle you describe above. And if supporting live update as a general feature for all users of the kernel isn't being factored into design considerations, then that needs to change, otherwise this is all dead in the water.

I also don't see the point. Maintaining a rigid save/restore ABI is annoying, but it's not _hard_ (or at least, not _that_ hard), especially if there's a set

Quoted 2 lines · Sean Christopherson

The rule is thou shalt not break userspace. Whether or not the breakage is the result of an explicit ABI change is irrelevant.

I argued strongly for this simpler approach, I will write here the reasoning I gave.

Firstly, "live update" is not uABI per-say. It is not "userspace breaking", and it is not a "regression". It is an internal kernel mechanism to allow the kernel to self-upgrade. In the industry it is typical any of these hitless update/patch/etc schemes to only work between a few tightly controlled version pairs.

Asking upstream to carry a full matrix of every single version pair ever released is massive over-engineering and cost on upstream maintainers. Refusing to do this is not a uABI breakage, it is not a regression, it is simply a lack of a feature.

I think upstream should start by agreeing to only support forward going upgrades within a single stable branch. If live update becomes a success then maybe we could do from a stable branch to the immediate next stable branch too. I don't know.

This alone is already much more powerful than live patching.

The balancing issue here is the impact on the kernel subsystems adopting luo. Every time you change anything about the internal function of the subystem you now have to go test a massive version pair matrix to make sure everything works? No thanks.

Luo is very invasive and a huge PITA at the best of times. It doesn't need to be even worse.

Quoted 5 lines

It's probably fine for Google and other large companies that tightly control their kernels and use cases, and have the resources to juggle the resulting complexity, e.g. have kernel engineers on staff to track feature and dependencies, coordinate and plan kernel upgrades, etc.

Every downstream that wants to support luo is going to necessarily severely restrict the version pairs that can work. Like a RH type distro may only support it for 9.1.x -> 9.1.x+1 - they can carry the cost of figuring out how to manage their patching and compatability matrix on their own with the tools upstream provides.

Quoted 4 lines

engineers on staff to help them thread the needle you describe above. And if supporting live update as a general feature for all users of the kernel isn't being factored into design considerations, then that needs to change, otherwise this is all dead in the water.

General uses can use upstream and do CVE upgrades within a single stable branch. That's good enough, lets start there. We don't need to boil the ocean.

Quoted 3 lines

I also don't see the point. Maintaining a rigid save/restore ABI is annoying, but it's not _hard_ (or at least, not _that_ hard), especially if there's a set

I was told KVM had the smallest luo footprint of everything, so perhaps your perspective is different.

In other places luo becomes coupled to the internal datastructures of the kernel, we literally have to preserve lots of kernel memory utterly unchanged without any kind of serialization at all.

This inevitably creates restrictions on the evolution of the kernel in general if we can no longer change in-kernel architecture because it would make some data structure incompatible with a kernel 10 years old.

There is also a need for *downgrade*. Meaning the N+1 kernel has to strictly emulate the limitations and capabilities of the N kernel so it can be rolled back. Can you imagine the nightmare of trying to codify the feature progression for every single kernel release forever in some impossible scheme to enable this? Again, no thanks.

So, what upstream can reasonably do, that still provides real value without severely burdening every subsystem, is upgrades within a stable kernel branch only.

If some distro or CSP wants to do more, they can deal with it. They have a far, far simpler problem because they can exactly lock down their version pairs to a very small universe. They don't need a single kernel that can emulate 10 different releases of behaviors concurrently.

Jason

From that perspective, what I am proposing actually goes a step further. I'm saying don't commit to supporting *any* specific versions in upstream. Express the feature requirements in the serialization payloads, and let userspace sort out what kernels are compatible based on their actual usage. The kernel may need to provide additional discovery mechanisms, e.g. so that userspace can probe to see what is supported, but discovery is usually fairly simple to implement and maintain.

No, the subsystem just needs to make sure that it serializes its data using the defined ABI (where ABI here means the format of the payload and the meaning of any flags in the header). That should be *easier* for maintainers to handle than trying to support arbitrary versions, because it eliminates subjectivity and having to make judgment calls or remember magic version numbers.

Quoted 2 lines

I was told KVM had the smallest luo footprint of everything, so perhaps your perspective is different.

Only because KVM already has a massive ABI surface for save/restore.

If you want to convince me that magic version numbers are the right approach, then show me how KVM's existing save/restore support would be made "better" and easier to maintain by throwing away all of KVM's save/restore uAPI and replacing it with a versioning scheme.

Have to, or choose to? I have a very, very hard time believing that it's infeasible to define a serialization format that is decoupled from kernel internals.

Only if the relevant subsystem defined a poor save/restore ABI in the first place.

Quoted 2 lines · Sean Christopherson

Quoted 1 line · Pratyush Yadav

On Tue, Aug 11 2026, Sean Christopherson wrote:

[...]

Quoted 9 lines

But that's all beside the point. What I'm saying is that SNP and TDX *must* use guest_memfd, whereas guest_memfd is optional for all other VM types. And so adding LUO support for guest_memfd without even sketching out a plan for CoCo VMs feels backwards.

I'm not necessarily opposed to gradual guest_memfd support, but there needs to be a clear plan of how all of this is going to fit together. It doesn't need to be perfect, and I'm sure we'll make mistakes along the way, but I want to at least try not to paint ourselves into a corner, especially with respect to the ABI.

Right. I think landing shared guest_memfd is the first step. It is simple enough and doesn't need to preserve the more complicated architecture specific things like secure EPT, etc. The CoCo support can build on top of this.

There is work underway already for an RFC of TDX live update, but Tarun knows the details better than me so I'll let him fill in the details for the next version of this series.

Quoted 42 lines

Quoted 24 lines

Quoted 24 lines

Quoted 9 lines

Quoted 5 lines

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.

I think it is fine if you want to take these changes through the KVM tree, but I would like live update maintainers to be listed as reviewers at least.

Why not simply add a file pattern match to the LIVE UPDATE entry?

MAINTAINERS +1 -1

index 8014b9f8253e..2eb57b22c37f 100644
@@ -15052,8 +15052,8 @@ F:      include/linux/liveupdate.h
 F:     include/uapi/linux/liveupdate.h
 F:     kernel/liveupdate/
 F:     lib/tests/liveupdate.c
-F:     mm/memfd_luo.c
 F:     tools/testing/selftests/liveupdate/
+N:     [^a-z]luo
 

Quoted 4 lines

MAINTAINERS F: include/linux/liveupdate.h · line 15059

Quoted 2 lines

MAINTAINERS +0 -0

 LLC (802.2)
 L:     [email protected]

This would list us as maintainers of kvm_luo.c and the tree as liveupdate.git,

It would list both "LIVE UPDATE" and "KERNEL VIRTUAL MACHINE (KVM)", as KVM would
still cover the files via "F: virt/kvm/*". And my read of MAINTAINERS is that
N: and K: entries are "secondary" if the files/scope is covered by an F: entry.

E.g. arch/x86/kvm/vmx/tdx.c is covered by "KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)"
via "F: arch/x86/kvm/*/", and also by "X86 TRUST DOMAIN EXTENSIONS (TDX)" via
"N: tdx" (or maybe "K: \b(tdx)"? I haven't bothered to check which one
triggers). And while I don't think there was ever any formal discussion, AFAIK everyone reads the situation as KVM still being the primary maintainer/tree for that code.

Quoted 1 line

both of which is something you're saying you _don't_ want.

Quoted 8 lines

No, what I don't want is a dedicated "KVM LIVE UPDATE" entry, because I think most
people would read "F: virt/kvm/kvm_luo.c" and "F: virt/kvm/guest_memfd_luo.c"
as being more precise than KVM's "F: virt/kvm/*" and thus would read things as
"KVM LIVE UPDATE" being the primary maintainer.

In other words, I'm more than ok with LUO being looped in on KVM LUO changes and having the authority to object to problematic changes, but I'm not ok with LUO taking primary ownership of KVM code.

Sure, that sounds good to me.

Quoted 1 line

Quoted 3 lines

I realize there's more than a bit of nuance in my interpretation of N: and K:, but again my experience with TDX is that so long as the maintainers are aligned on expectations, it's a non-issue in practice.

Yep, as long as we agree among ourselves I don't think the red tape around which entry has higher priority matters much.

Quoted 33 lines

Quoted 23 lines

Quoted 11 lines

Quoted 9 lines

At the same time, I also keep being (pleasantly)
surprised at preservation being relatively simple. For example, the code to preserve a shmem file (via memfd) is roughly 600 lines, a big chunk of which is comments. The code of course has some limitations, but it is good enough for use in production.

For one, we care about ABI breakages and versioning.

Which is amusing to me because that implies KVM does not, and I would hazard to

No, it doesn't. What I'm saying is I care about changes to the _live update ABI_. Just like you probably care about changes to KVM ABI but not so much about BPF for example.

Quoted 7 lines

guess that KVM has the biggest ABI surface of any subsystem in the kernel by a country mile (though I'm probably wildly underestimating the effective ABI surface of filesystems).

Quoted 2 lines

The serialized state is a part of live update ABI and changes to it should be ACKed by us.

Quoted 7 lines

Quoted 2 lines

Meh, "Don't break userspace" is a universal rule in the kernel, I genuinely don't see why liveupdate needs special treatment.

Ironically enough, you miss my point. I'm not talking about userspace ABI. We all know not to break that. I am talking about live update _serialization ABI_. See the stuff under include/linux/kho/abi. This series also adds things there.

No, I understand exactly what ABI you're talking about.

Quoted 8 lines

Quoted 3 lines

This is ABI between kernels. It needs to be stable-ish so you can move from one kernel version to another. At the same time, unlike userspace ABI, it can change.

Uh, yeah, so KVM has been managing such immutable ABI for practically its entire existence. KVM's save/restore uAPI has exactly what you're describing: serialization ABI that needs to be backwards and forwards compatible between different kernels in order to support both upgrade and rollback scenarios via live migration.

I think there is a slight difference between KVM's save/resture uAPI and live update's ABI. With KVM's uAPI, you need to maintain strict backwards compatibility because userspace reads what you output. So if you change the layout, userspace will interpret it wrong and might break.

With live update, the ABI never gets to userspace. It is used to talk between kernels directly. So if you do break that, your userspace keeps working fine, you just might not be able to live update to the incompatible kernel.

So with live update, we don't need to keep backwards compatibility in the ABI forever. Of course, it is good to minimize changes, but we have more freedom to change it.

The current idea is we change the ABI whenever needed. This is because live update is still in development so we are likely to see a lot more changes before we settle down into something that mostly works. At some point, we want to start being more strict between incompatible ABI changes. The current idea is that we would like to keep backwards compatibility across LTS kernels. But none of that is set in stone yet.

That's why I would like to have an explicit ACK from the live update group for ABI changes. I would like to enforce these compatibility windows.

Quoted 20 lines

KVM also has immutable ABI between itself and guest kernels, including implicit "ABI" in the form of not changing guest-visible behavior.

Quoted 7 lines

Today we don't have any rules and let you change things freely as long as you do a version bump. But at a later point, the plan is to add some stability requirements to the ABI so you can actually upgrade the kernel across major versions.

So at least for ABI changes, there should be an explicit ACK from the live update group.

I don't entirely agree. I get where you're coming from, and I 100% agree that the more eyeballs on changes that may affect ABI, the better.

Where I have problems with the above is that it doesn't account for the nuances of save/restore across different kernels. The literal format of the serialized data is the most obvious form of ABI, but it's absolutely possible to change ABI without changing the data format.

Quoted 6 lines

E.g. say there's a flags field in some serialization structure, and flags X and Y are mutually exclusive in current kernels. If a future kernel relaxes that restriction for whatever reason, then the effective ABI has been broken because state created and saved on new kernels can't be restored on old kernels. And this is not a theoretical concern, KVM has run afoul of this a few times (though thankfully very rarely).

That's a bug, and should be fixed.

I am talking here about intentional ABI changes. As I mentioned above we _can_ change the ABI, we just need to be careful about it.

Quoted 9 lines

I don't think it's reasonable to expect LUO maintainers to gain enough expertise in each subsystem to be able to ensure changes are forwards and backwards compatible. The only way I see LUO being successful in the long term is to get subsystem maintainers/contributors to understand *and buy-in* to the LUO model and rules, so that each subsystem can largely be self-sustatining. I.e. setting yourselves up as literal gatekeepers will help prevent blatant breakage, but it's less likely to help guard against more subtle breakage, and in my experience, subtle breakage is by far harder to detect and more painful to deal with.

Outside of enforcing the ABI compatibility windows, I think this makes sense.

In principle at least, though from my experience the maintainer appetite to care about live update varies. The feeling I've got from MM for example is more along the lines of "you break it, you buy it". Which is also a valid model IMO. The person who wrote the live update code for a subsystem is well equipped to understand these nuances.

Quoted 5 lines

Somewhat of a side topic: in my experience, using monotonically increasing version numbers is a horrible way to enumerate features/content. So for me, allowing KVM's LUO ABI to change with a verson bump is probably a non-starter. I.e. whatever gets merged needs to be more future-proof than "we'll deal with it later".

As I wrote above, the compatibility model for live update allows breaking ABI with version bumps. Userspace keeps working fine, it only restricts the set of kernels that you can go to. So the "we'll deal with it later" is not as harmful because our choices here are not permanent.

Also, there is work underway to allow transitions between versions [0].

But still, I am not opposed to a more flexible guest_memfd ABI. I think we can reserve some space for feature flags to let us add things in the future.

[0] https://lore.kernel.org/kexec/[email protected]/

Signature · 2 lines

Regards,
Pratyush Yadav

Quoted 21 lines · Pratyush Yadav

Quoted 19 lines · Sean Christopherson

Quoted 5 lines · Tarun Sahu

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?

Quoted 9 lines

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.

Quoted 7 lines

Quoted 4 lines

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.

You _can_ preserve vCPUs today using KVM_{GET,SET}_REGS, they just won't run in the background during the reboot.

What about x86 CoCo VMs? Which are quite literally _the_ reason guest_memfd was created in the first place.

Quoted 2 lines

This series can save you from dumping VM memory to disk if it is backed by guest_memfd.

Or to word it another way, one _can_ save guest_memfd, it's just slower.

My point is that this series needs to provide a _lot_ more information about the bigger KVM picture.

For those of us that are on the very fringes of live update,
it's practically impossible to review because, to us, it seems very arbitrary.

The part that's especially confusing is the saving of the VM type. That comes straight from userspace, so it's super bizarre to automatically save/restore that, but nothing else.

Quoted 16 lines

Quoted 16 lines

Review

Quoted 10 lines

(quoted diff) +9 -0

+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

...

Quoted 7 lines

Quoted 3 lines

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.

I think it is fine if you want to take these changes through the KVM tree, but I would like live update maintainers to be listed as reviewers at least.

Why not simply add a file pattern match to the LIVE UPDATE entry?

MAINTAINERS +1 -1

index 8014b9f8253e..2eb57b22c37f 100644
@@ -15052,8 +15052,8 @@ F:      include/linux/liveupdate.h
 F:     include/uapi/linux/liveupdate.h
 F:     kernel/liveupdate/
 F:     lib/tests/liveupdate.c
-F:     mm/memfd_luo.c
 F:     tools/testing/selftests/liveupdate/
+N:     [^a-z]luo
 
 LLC (802.2)
 L:     [email protected]

Quoted 8 lines

At the same time, I also keep being (pleasantly)
surprised at preservation being relatively simple. For example, the code to preserve a shmem file (via memfd) is roughly 600 lines, a big chunk of which is comments. The code of course has some limitations, but it is good enough for use in production.

For one, we care about ABI breakages and versioning.

Which is amusing to me because that implies KVM does not, and I would hazard to guess that KVM has the biggest ABI surface of any subsystem in the kernel by a country mile (though I'm probably wildly underestimating the effective ABI surface of filesystems).

Quoted 2 lines

The serialized state is a part of live update ABI and changes to it should be ACKed by us.

Meh, "Don't break userspace" is a universal rule in the kernel, I genuinely don't see why liveupdate needs special treatment.

Quoted 3 lines

For another, how the file handlers interact with their dependencies can affect the behaviour that VMMs observe. Those changes should also pass by some live update eyes.

Perhaps in the short term, but IMO, that's not a winning strategy in the long term. From my perspective, that like saying the PAGE CACHE maintainers should review every usage of the filemap APIs, because how the APIs are used impacts the page cache and affects userspace-visible behavior. There are myriad analogies like that throughout the kernel.

Yes, liveupdate is new and shiny, but IMO for it to be successful and maintainable, it needs to be treated like any other core infrastructure in the kernel, not a special snowflake whose details are known only by a handful of people. Because I think it's likely liveupdate goes one of two ways: either liveupdate becomes a very niche thing that is used sparingly throughout the kernel, or it becomes a broadly used feature that is supported by many filesystems and subsystems.

If liveupdate is relegated to niche status, then it probably isn't going to see a significant amount of ongoing development, at which point the folks working on liveupdate will naturally migrate to other projects, and maintenance will largely be left to subsystem maintainers.

If liveupdate is broadly used, then having a single group of people maintain every subsystem's usage won't scale, and maintenance will again largely fall on the shoulder of subsystem maintainers. Which is totally fine and working as intended, because that's exactly what subystem maintainers are signing up for by merging support for liveupdate.

Extract 'struct gmem_file', 'struct gmem_inode', and GMEM_I() from virt/kvm/guest_memfd.c into a new internal header virt/kvm/guest_memfd.h. Also split __kvm_gmem_create() to expose a non-static __kvm_gmem_create_file() helper that returns a 'struct file *' instead of an fd.

These internal definitions and helpers allow upcoming guest_memfd Live Update Orchestrator (LUO) preservation code to access guest_memfd internals and reconstruct guest_memfd file instances from preserved state without installing them into a file descriptor table up front.

Signed-off-by Tarun Sahu <[email protected]>

---
 virt/kvm/guest_memfd.c | 68 +++++++++++++++++-------------------------
 virt/kvm/guest_memfd.h | 39 ++++++++++++++++++++++++
 2 files changed, 67 insertions(+), 40 deletions(-)
 create mode 100644 virt/kvm/guest_memfd.h

virt/kvm/guest_memfd.c +28 -40

index db57c5766ab6..dd84bba8974b 100644
@@ -7,38 +7,12 @@
 #include <linux/mempolicy.h>
 #include <linux/pseudo_fs.h>
 #include <linux/pagemap.h>
+#include "guest_memfd.h"
 
 #include "kvm_mm.h"
 
 static struct vfsmount *kvm_gmem_mnt;
 
-/*
- * A guest_memfd instance can be associated multiple VMs, each with its own
- * "view" of the underlying physical memory.
- *
- * The gmem's inode is effectively the raw underlying physical storage, and is
- * used to track properties of the physical memory, while each gmem file is
- * effectively a single VM's view of that storage, and is used to track assets
- * specific to its associated VM, e.g. memslots=>gmem bindings.
- */
-struct gmem_file {
-	struct kvm *kvm;
-	struct xarray bindings;
-	struct list_head entry;
-};
-
-struct gmem_inode {
-	struct shared_policy policy;
-	struct inode vfs_inode;
-	struct list_head gmem_file_list;
-
-	u64 flags;
-};
-
-static __always_inline struct gmem_inode *GMEM_I(struct inode *inode)
-{
-	return container_of(inode, struct gmem_inode, vfs_inode);
-}
 
 #define kvm_gmem_for_each_file(f, inode) \
 	list_for_each_entry(f, &GMEM_I(inode)->gmem_file_list, entry)

@@ -557,23 +531,17 @@ bool __weak kvm_arch_supports_gmem_init_shared(struct kvm *kvm)
 	return true;
 }
 
-static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags)
+struct file *__kvm_gmem_create_file(struct kvm *kvm, loff_t size, u64 flags)
 {
 	static const char *name = "[kvm-gmem]";
 	struct gmem_file *f;
 	struct inode *inode;
 	struct file *file;
-	int fd, err;
-
-	fd = get_unused_fd_flags(0);
-	if (fd < 0)
-		return fd;
+	int err;
 
 	f = kzalloc_obj(*f);
-	if (!f) {
-		err = -ENOMEM;
-		goto err_fd;
-	}
+	if (!f)
+		return ERR_PTR(-ENOMEM);
 
 	/* __fput() will take care of fops_put(). */
 	if (!fops_get(&kvm_gmem_fops)) {

@@ -612,8 +580,7 @@ static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags)
 	xa_init(&f->bindings);
 	list_add(&f->entry, &GMEM_I(inode)->gmem_file_list);
 
-	fd_install(fd, file);
-	return fd;
+	return file;
 
 err_inode:
 	iput(inode);

@@ -621,7 +588,28 @@ static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags)
 	fops_put(&kvm_gmem_fops);
 err_gmem:
 	kfree(f);
-err_fd:
+	return ERR_PTR(err);
+}
+
+static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags)
+{
+	struct file *file;
+	int fd, err;
+
+	fd = get_unused_fd_flags(0);
+	if (fd < 0)
+		return fd;
+
+	file = __kvm_gmem_create_file(kvm, size, flags);
+	if (IS_ERR(file)) {
+		err = PTR_ERR(file);
+		goto err_put_fd;
+	}
+
+	fd_install(fd, file);
+	return fd;
+
+err_put_fd:
 	put_unused_fd(fd);
 	return err;
 }

virt/kvm/guest_memfd.h new file +39 -1

new file mode 100644
index 000000000000..c528b046dd69
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __KVM_GUEST_MEMFD_H__
+#define __KVM_GUEST_MEMFD_H__ 1
+
+#include <linux/kvm_host.h>
+#include <linux/fs.h>
+#include <linux/mempolicy.h>
+
+/*
+ * A guest_memfd instance can be associated multiple VMs, each with its own
+ * "view" of the underlying physical memory.
+ *
+ * The gmem's inode is effectively the raw underlying physical storage, and is
+ * used to track properties of the physical memory, while each gmem file is
+ * effectively a single VM's view of that storage, and is used to track assets
+ * specific to its associated VM, e.g. memslots=>gmem bindings.
+ */
+struct gmem_file {
+	struct kvm *kvm;
+	struct xarray bindings;
+	struct list_head entry;
+};
+
+struct gmem_inode {
+	struct shared_policy policy;
+	struct inode vfs_inode;
+	struct list_head gmem_file_list;
+
+	u64 flags;
+};
+
+static inline struct gmem_inode *GMEM_I(struct inode *inode)
+{
+	return container_of(inode, struct gmem_inode, vfs_inode);
+}
+
+struct file *__kvm_gmem_create_file(struct kvm *kvm, loff_t size, u64 flags);
+
+#endif /* __KVM_GUEST_MEMFD_H__ */
--

2.55.0.229.g6434b31f56-goog

Quoted 6 lines · Tarun Sahu

Extract 'struct gmem_file', 'struct gmem_inode', and GMEM_I() from virt/kvm/guest_memfd.c into a new internal header virt/kvm/guest_memfd.h. Also split __kvm_gmem_create() to expose a non-static __kvm_gmem_create_file() helper that returns a 'struct file *' instead of an fd.

This is done basically to support a new virt/kvm/guest_memfd_luo.c file.

Would like to know what Sean thinks of this! I'd like to know for future guest_memfd work too.

Quoted 6 lines

These internal definitions and helpers allow upcoming guest_memfd Live Update Orchestrator (LUO) preservation code to access guest_memfd internals and reconstruct guest_memfd file instances from preserved state without installing them into a file descriptor table up front.

Signed-off-by Tarun Sahu <[email protected]>

Introduce kvm_gmem_freeze() to freeze a guest_memfd inode's mapping, which prevents fallocate() operations and new page fault allocations during preservation.

Use a global SRCU (kvm_gmem_freeze_srcu) to synchronize freeze state checkers without incurring per-fault locking overhead or risking per-CPU memory exhaustion (as per-CPU structure not counted in cgroup) from per-inode SRCU structures by faulty/compromised VMM.

Signed-off-by Tarun Sahu <[email protected]>

[...snip...]

Quoted 4 lines · Tarun Sahu

Introduce kvm_gmem_freeze() to freeze a guest_memfd inode's mapping, which prevents fallocate() operations and new page fault allocations during preservation.

Quoted 5 lines

Use a global SRCU (kvm_gmem_freeze_srcu) to synchronize freeze state checkers without incurring per-fault locking overhead or risking per-CPU memory exhaustion (as per-CPU structure not counted in cgroup) from per-inode SRCU structures by faulty/compromised VMM.

I wonder if everything to do with freezing should be gated behind CONFIG_LIVEUPDATE_GUEST_MEMFD. What do people think?

Quoted 5 lines

Signed-off-by Tarun Sahu <[email protected]>

[...snip...]

[...snip...]

virt/kvm/guest_memfd.c +11 -6

@@ -273,16 +284,30 @@ static long kvm_gmem_allocate(struct inode *inode, loff_t offset, loff_t len)
 static long kvm_gmem_fallocate(struct file *file, int mode, loff_t offset,
 			       loff_t len)
 {
+	struct inode *inode = file_inode(file);
 	int ret;
+	int idx;
 
-	if (!(mode & FALLOC_FL_KEEP_SIZE))
-		return -EOPNOTSUPP;
+	idx = srcu_read_lock(&kvm_gmem_freeze_srcu);
+	if (kvm_gmem_is_frozen(inode)) {
+		srcu_read_unlock(&kvm_gmem_freeze_srcu, idx);
+		return -EPERM;
+	}
 
-	if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
-		return -EOPNOTSUPP;
+	if (!(mode & FALLOC_FL_KEEP_SIZE)) {
+		ret = -EOPNOTSUPP;
+		goto out;
+	}
 
-	if (!PAGE_ALIGNED(offset) || !PAGE_ALIGNED(len))
-		return -EINVAL;

virt/kvm/guest_memfd.c +3 -0

 	if (mode & FALLOC_FL_PUNCH_HOLE)
 		ret = kvm_gmem_punch_hole(file_inode(file), offset, len);

@@ -291,6 +316,9 @@ static long kvm_gmem_fallocate(struct file *file, int mode, loff_t offset,
 
 	if (!ret)
 		file_modified(file);
+
+out:
+	srcu_read_unlock(&kvm_gmem_freeze_srcu, idx);
 	return ret;
 }
 
 
[...snip...]

Quoted 28 lines · Tarun Sahu

[...snip...]

virt/kvm/guest_memfd.c +11 -6

@@ -273,16 +284,30 @@ static long kvm_gmem_allocate(struct inode *inode, loff_t offset, loff_t len)
 static long kvm_gmem_fallocate(struct file *file, int mode, loff_t offset,
 			       loff_t len)
 {
+	struct inode *inode = file_inode(file);
 	int ret;
+	int idx;
 
-	if (!(mode & FALLOC_FL_KEEP_SIZE))
-		return -EOPNOTSUPP;
+	idx = srcu_read_lock(&kvm_gmem_freeze_srcu);
+	if (kvm_gmem_is_frozen(inode)) {
+		srcu_read_unlock(&kvm_gmem_freeze_srcu, idx);
+		return -EPERM;
+	}
 
-	if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
-		return -EOPNOTSUPP;
+	if (!(mode & FALLOC_FL_KEEP_SIZE)) {
+		ret = -EOPNOTSUPP;
+		goto out;
+	}
 
-	if (!PAGE_ALIGNED(offset) || !PAGE_ALIGNED(len))
-		return -EINVAL;

virt/kvm/guest_memfd.c static long kvm_gmem_allocate(struct inode *inode, loff_t offset, loff_t len) · line 311

Quoted 10 lines

virt/kvm/guest_memfd.c +9 -0

+	if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE)) {
+		ret = -EOPNOTSUPP;
+		goto out;
+	}
+
+	if (!PAGE_ALIGNED(offset) || !PAGE_ALIGNED(len)) {
+		ret = -EINVAL;
+		goto out;
+	}
 

Continuing from [1], this guard is actually meant for PUNCH_HOLE... I wonder if there could be a deeper refactoring to check when actually punching a hole, basically the equivalent place as kvm_gmem_get_folio() in the flow of fallocating.

Will srcu_read_lock() be taken in a nested way for the fallocate case? It can be taken in a nested way with some intricacies, but maybe if the freeze check can be done just as the folio is about to be removed (as described in the above paragraph), it would avoid this nested locking here.

[1] https://lore.kernel.org/all/[email protected]/

Quoted 16 lines

virt/kvm/guest_memfd.c +3 -0

 	if (mode & FALLOC_FL_PUNCH_HOLE)
 		ret = kvm_gmem_punch_hole(file_inode(file), offset, len);

@@ -291,6 +316,9 @@ static long kvm_gmem_fallocate(struct file *file, int mode, loff_t offset,
 
 	if (!ret)
 		file_modified(file);
+
+out:
+	srcu_read_unlock(&kvm_gmem_freeze_srcu, idx);
 	return ret;
 }
 
 
[...snip...]

+/**
+ * kvm_gmem_freeze - Freeze or unfreeze a guest_memfd inode mapping.
+ * @inode: The guest_memfd inode.
+ * @freeze: True to freeze, false to unfreeze.
+ *
+ * This API is used strictly during the live update / preservation transition
+ * window to prevent host userspace and guest-side faults from making any
+ * mapping modifications (such as fallocate or page fault allocation)
+ * to the guest_memfd page cache.
+ *
+ * Synchronization Strategy (Sleepable RCU):
+ * To avoid high-contention VFS locks (like inode_lock or
+ * filemap_invalidate_lock) on the vCPU page fault hot paths, this subsystem

+ * implements a lightweight, system-wide Sleepable RCU (SRCU) mechanism
+ * (kvm_gmem_freeze_srcu):
+ *
+ * Global vs. Per-Inode SRCU
+ * ======================
+ * A single system-wide global static srcu_struct is used instead of a
+ * per-inode SRCU structure to completely prevent unprivileged users from
+ * exhausting the host's per-CPU memory allocator.

Quoted 13 lines · Tarun Sahu

+/**
+ * kvm_gmem_freeze - Freeze or unfreeze a guest_memfd inode mapping.
+ * @inode: The guest_memfd inode.
+ * @freeze: True to freeze, false to unfreeze.
+ *
+ * This API is used strictly during the live update / preservation transition
+ * window to prevent host userspace and guest-side faults from making any
+ * mapping modifications (such as fallocate or page fault allocation)
+ * to the guest_memfd page cache.
+ *
+ * Synchronization Strategy (Sleepable RCU):
+ * To avoid high-contention VFS locks (like inode_lock or
+ * filemap_invalidate_lock) on the vCPU page fault hot paths, this subsystem

Quoted 8 lines

+ * implements a lightweight, system-wide Sleepable RCU (SRCU) mechanism
+ * (kvm_gmem_freeze_srcu):
+ *
+ * Global vs. Per-Inode SRCU
+ * ======================
+ * A single system-wide global static srcu_struct is used instead of a
+ * per-inode SRCU structure to completely prevent unprivileged users from
+ * exhausting the host's per-CPU memory allocator.

This argument doesn't hold up given that each kvm structure has two SRCU structs.

[...snip...]

virt/kvm/guest_memfd_luo.c new file +9 -0

+static bool kvm_gmem_luo_can_preserve(struct liveupdate_file_handler *handler, struct file *file)
+{
+	struct inode *inode = file_inode(file);
+	struct gmem_file *gmem_file;
+	struct kvm *kvm;
+
+	if (inode->i_sb->s_magic != GUEST_MEMFD_MAGIC)
+		return false;
+

virt/kvm/guest_memfd_luo.c new file +6 -0

+	if (mapping_large_folio_support(inode->i_mapping))
+		return false;
+
+	return true;
+}
+
 
[...snip...]

Quoted 19 lines · Tarun Sahu

[...snip...]

virt/kvm/guest_memfd_luo.c new file +16 -0

+static bool kvm_gmem_luo_can_preserve(struct liveupdate_file_handler *handler, struct file *file)
+{
+	struct inode *inode = file_inode(file);
+	struct gmem_file *gmem_file;
+	struct kvm *kvm;
+
+	if (inode->i_sb->s_magic != GUEST_MEMFD_MAGIC)
+		return false;
+
+	gmem_file = file->private_data;
+	if (!gmem_file)
+		return false;
+
+	/*
+	 * Only Fully-shared guest_memfd preservation is supported
+	 */

virt/kvm/guest_memfd_luo.c line 124

Quoted 3 lines

virt/kvm/guest_memfd_luo.c new file +3 -0

+	if (!(GMEM_I(inode)->flags & GUEST_MEMFD_FLAG_INIT_SHARED))
+		return false;
+

The above check can probably be removed. I think the core thing about this series is "we can preserve any memory that doesn't have any encryption state that goes along with it", and so the check for kvm_arch_has_private_mem() below would be sufficient to gate that.

virt/kvm/guest_memfd_luo.c line 133

Quoted 10 lines

virt/kvm/guest_memfd_luo.c new file +9 -0

+	/*
+	 * It makes sure that no memory can be converted to private
+	 * even if it was initially fully shared (in-place conversions are
+	 * prevented).
+	 */
+	kvm = gmem_file->kvm;
+	if (kvm_arch_has_private_mem(kvm))
+		return false;
+

For now, has_private_mem == has some encryption state that we can't preserve yet.

This also gates off KVM_X86_SW_PROTECTED_VM, but I guess that is intended, since when work is done for preserving encryption state, we can then test using KVM_X86_SW_PROTECTED_VM, and only then, remove this check?

Quoted 10 lines

virt/kvm/guest_memfd_luo.c new file +6 -0

+	if (mapping_large_folio_support(inode->i_mapping))
+		return false;
+
+	return true;
+}
+
 
[...snip...]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Mismatched kernel-doc section titles cause Sphinx build warnings and missing documentation. --

--- Patch [9]: [PATCH v4 09/11] docs: liveupdate: Add documentation for VM and guest_memfd preservation --- commit a930d2f58a9edc06bdcfd10fb383e97d7fe3996c
Author: Tarun Sahu <[email protected]>

docs: liveupdate: Add documentation for VM and guest_memfd preservation

Add Documentation/liveupdate/vmm.rst detailing VMM requirements, scope, ordering constraints, and kernel-doc inclusions for KVM VM and guest_memfd preservation via Live Update Orchestrator (LUO).

Quoted 7 lines

Documentation/liveupdate/vmm.rst new file +1 -0

new file mode 100644
index 0000000000000..b8e8fb2b63c21
@@ -0,0 +1,107 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later

Documentation/liveupdate/vmm.rst line 11

Quoted 10 lines

Documentation/liveupdate/vmm.rst new file +10 -0

+
+=============================
+VM & Guest_Memfd Preservation
+=============================
+
+.. kernel-doc:: virt/kvm/kvm_luo.c
+   :doc: KVM VM Preservation via LUO
+
+.. kernel-doc:: virt/kvm/guest_memfd_luo.c
+   :doc: Guest_Memfd Preservation via LUO

[Severity: Low]
Does this section title exactly match the DOC: title in virt/kvm/guest_memfd_luo.c?