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

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Nov 18, 2025 at 10:03:03PM -0500, Pasha Tatashin wrote:
> On Tue, Nov 18, 2025 at 6:25 PM Jason Gunthorpe <jgg@nvidia.com> wrote:
> >
> > On Tue, Nov 18, 2025 at 05:07:15PM -0500, Pasha Tatashin wrote:
> >
> > > 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.
> 
> > 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