Re: [PATCH v6 02/20] liveupdate: luo_core: integrate with KHO

On Tue, Nov 18, 2025 at 10:03:03PM -0500, Pasha Tatashin wrote:

On Tue, Nov 18, 2025 at 6:25 PM Jason Gunthorpe [off-list ref] wrote:

quoted

On Tue, Nov 18, 2025 at 05:07:15PM -0500, Pasha Tatashin wrote:

quoted

In this case, we cannot even rely on having "safe" memory, i.e. this
scratch only boot to preserve dmesg/core etc, this is unfortunate. Is
there a way to avoid defaulting to identify mode when we are booting
into the "maintenance" mode?

Maybe one could be created?

It's tricky though because you also really want to block drivers from
using the iommu if you don't know they are quieted and you can't do
that without parsing the KHO data, which you can't do because it
doesn't understand it..

IDK, I think the "maintenance" mode is something that is probably best
effort and shouldn't be relied on. It will work if the iommu data is
restored or other lucky conditions hit, so it is not useless, but it
is certainly not robust or guaranteed.

Right, even kdump has always been best-effort; many types of crashes
do not make it to the crash kernel.

quoted

You are better to squirt a panic message out of the serial port and

For early boot LUO mismatches, or if FLB data is inaccessible for any
reason, devices might go rogue, so triggering a panic during boot is
appropriate.

However, session and file data structures are deserialized later, when
/dev/liveupdate is first opened by userspace. If deserialization fails
at that stage, I think we should simply fail the open(/dev/liveupdate)
call with an error such as -EIO.

That seems reasonable, if you reached this point then it is probably
OK.

Most likely the prior kernel should mark some critical things like kho,
iommu and pci data as 'madatory early boot' and if the new kernel
doesn't use them then blow up right away.

Jason