On Tue, Aug 5, 2025 at 12:31 PM Jason Gunthorpe [off-list ref] wrote:

On Sun, Aug 03, 2025 at 09:11:20PM -0400, Pasha Tatashin wrote:

quoted

Having a global state is necessary for performance optimizations. This
is similar to why we export the state to userspace via sysfs: it
allows other subsystems to behave differently during a
performance-optimized live update versus a normal boot.

quoted

For example, in our code base we have a driver that doesn't
participate in the live update itself (it has no state to preserve).
However, during boot, it checks this global state. If it's a live
update boot, the driver skips certain steps, like loading firmware, to
accelerate the overall boot time.

TBH, I'm against this. Give the driver a 0 byte state if it wants to
behave differently during live update. We should not be making
implicit things like this.

Plus the usual complaining about building core kernel infrastructure
around weird out of tree drivers.

If userspace wants a device to participate in live update, even just
"optimizations", then it has to opt in.

Frankly, this driver has no idea what the prior kernel did, and by
"optimizing" I think you are actually assuming that the prior kernel
had it bound to a normal kernel driver that left it in some
predictable configuration.

Fair enough, that subsystem / driver should simply participate in the
live update process normally.

Vs say bound to VFIO and completely messed up.

So this should be represented by a LUO serialization that says "the
prior kernel left this device in well defined state X" even if it
takes 0 bytes to describe that state.

So no globals, there should be a way for a driver to tell if it is
participating in LUO, but not some global 'is luo' boot fla.g

quoted

quoted

+       ret = liveupdate_register_subsystem(&luo_file_subsys);
+       if (ret) {
+               pr_warn("Failed to register luo_file subsystem [%d]\n", ret);
+               return ret;
+       }
+
+       if (liveupdate_state_updated()) {

Thats going to be a standard pattern - I would expect that
liveupdate_register_subsystem() would do the check for updated and
then arrange to call back something like
liveupdate_subsystem.ops.post_update()

I added another callback liveupdate_subsystem.ops.post_update(), which
gets called on live update, just when a subsystem registers with LUO,
because that is when we know that it is ready. I will send the new
patch version soon.

Thank you,
Pasha