[RFC,v1,0/3] Live Update Orchestrator

Message

Pasha Tatashin March 20, 2025, 2:40 a.m. UTC

From: Pasha Tatashin <[e-mail]>

This series applies on top of the kho v5 patch series:
https://lore.kernel.org/all/[e-mail]

The git branch for this series:
https://github.com/googleprodkernel/linux-liveupdate/commits/luo/rfc-v1

What is Live Update?
Live Update is a specialized reboot process where selected devices are
kept operational across a kernel transition. For these devices, DMA and
interrupt activity may continue uninterrupted during the kernel reboot.

Please find attached a series of three patches introducing the Live
Update Orchestrator (LUO), a new kernel subsystem designed to
facilitate live kernel updates with minimal downtime. The primary
use case is in cloud environments, allowing hypervisor updates without
fully disrupting running virtual machines by keeping selected devices
alive across the reboot boundary. This series also inroduces a device
layer infrastructure (dev_liveupdate) to be used with LUO.

The core of LUO is a state machine that tracks the progress of a live
update, along with a callback API that allows other kernel subsystems
to participate in the process. Example subsystems that can hook into LUO
include: kvm, iommu, interrupts, the Device Layer (through the
dev_liveupdate infrastructure introduced in patch 2), and mm.

LUO uses KHO to transfer memory state from Old Kernel to the New Kernel.

LUO can be controlled through sysfs interface. It provides the following
files under: `/sys/kernel/liveupdate/{state, prepare, finish}`

The `state` file can contain the following values:

normal
The system is operating normally, and no live update is in progress.
This is the initial state.

prepared
The system has begun preparing for a live update. This state is reached
after subsystems have successfully responded to the `LIVEUPDATE_PREPARE`
callback. It indicates that initial preparation is done, but it does not
necessarily mean all state has been serialized; subsystems can save more
state during the subsequent `LIVEUPDATE_REBOOT` callback.

updated
The new kernel has successfully taken over, and any suspended operations
are resumed. However, the system has not yet fully transitioned back to
a normal operational state; this happens after the `LIVEUPDATE_FINISH`
callback is invoked.

Writing '1' to the `prepare` file triggers a transition from normal
to prepared (if possible), which involves invoking the
`LIVEUPDATE_PREPARE` notifiers. Similarly, writing to the `finish` file
attempts a transition to the normal state from updated via the
`LIVEUPDATE_FINISH` notifiers.

The state machine ensures that operations are performed in the correct
sequence and provides a mechanism to track and recover from potential
failures, and select devices and subsystems that should participate in
live update sequence.

==============
dev_liveupdate
==============

To allow device drivers and bus drivers to participate, the second patch
introduces the `dev_liveupdate` infrastructure. This provides a
`liveupdate()` callback in `struct device_driver` and `struct bus_type`,
which receives the LUO state machine events.

The `dev_liveupdate` component also adds a "liveupdate" sysfs directory
under each device (e.g., `/sys/devices/.../device/liveupdate/`). This
directory contains the following attributes:

`requested`
A read-write attribute allowing userspace to control whether a device
should participate in the live update sequence. Writing `1` requests the
device and its ancestors (that support live update) be preserved.
Writing `0` requests the device be excluded. This attribute can only be
modified when LUO is in the `normal` state.

`preserved`
A read-only attribute indicating whether the device's state was
preserved during the `prepare` and `reboot` stages.

`reclaimed`
A read-only attribute indicating whether the device was successfully
re-attached and resumed operation in the new kernel after an update.
For example, a VM to which this device was passthrough has been resumed.

By default, devices do not participate in the live update. Userspace can
explicitly request participation by writing '1' to the `requested` file.

TODO:
- Expand, improve, clean-up documentation
- Embed a flow chart via Graphviz
- Add selftests for LUO and dev_liveupdate
- Add debug interface to allow LUO to perform LIVEUPDATE_REBOOT via sysfs
  to help developers of subsystems and device drivers.
- dev_liveupdate should add KHO node names to dev / drivers/ bus, and also
  dev->lu should contain a link to a KHO node for this device that is allocated
  and freed through dev_liveupdate
- dev_liveupdate should also partcipate during boot to track the reclaimed
  devices

Pasha Tatashin (3):
  luo: Live Update Orchestrator
  luo: dev_liveupdate: Add device live update infrastructure
  luo: x86: Enable live update support

 .../ABI/testing/sysfs-kernel-liveupdate       |  51 ++
 Documentation/admin-guide/index.rst           |   1 +
 Documentation/admin-guide/liveupdate.rst      |  23 +
 Documentation/driver-api/index.rst            |   1 +
 Documentation/driver-api/liveupdate.rst       |  23 +
 MAINTAINERS                                   |  13 +
 arch/x86/Kconfig                              |   1 +
 drivers/base/Makefile                         |   1 +
 drivers/base/core.c                           |  25 +-
 drivers/base/dev_liveupdate.c                 | 816 ++++++++++++++++++
 include/linux/dev_liveupdate.h                | 109 +++
 include/linux/device.h                        |   6 +
 include/linux/device/bus.h                    |   4 +
 include/linux/device/driver.h                 |   4 +
 include/linux/liveupdate.h                    | 238 +++++
 init/Kconfig                                  |   2 +
 kernel/Kconfig.liveupdate                     |  19 +
 kernel/Makefile                               |   1 +
 kernel/liveupdate.c                           | 749 ++++++++++++++++
 kernel/reboot.c                               |   4 +
 20 files changed, 2083 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-kernel-liveupdate
 create mode 100644 Documentation/admin-guide/liveupdate.rst
 create mode 100644 Documentation/driver-api/liveupdate.rst
 create mode 100644 drivers/base/dev_liveupdate.c
 create mode 100644 include/linux/dev_liveupdate.h
 create mode 100644 include/linux/liveupdate.h
 create mode 100644 kernel/Kconfig.liveupdate
 create mode 100644 kernel/liveupdate.c

Comments

Greg KH March 20, 2025, 1:35 p.m. UTC | #1

On Thu, Mar 20, 2025 at 02:40:08AM +0000, Pasha Tatashin wrote:
> From: Pasha Tatashin <[e-mail]>

Note, this does not match the author and signed-off-by on the actual
patches themselves.  Please use your google.com email address to
send/review/work on this.

thanks,

greg k-h

Pasha Tatashin March 20, 2025, 3:34 p.m. UTC | #2

> > From: Pasha Tatashin <[e-mail]>
>
> Note, this does not match the author and signed-off-by on the actual
> patches themselves.  Please use your google.com email address to
> send/review/work on this.

This  was accidental, I meant to use [e-mail] here, I
use this e-mail for upstream work.