Re: [RFC v2 05/16] luo: luo_core: integrate with KHO

[Pasha Tatashin]

On Tue, Jun 17, 2025 at 11:24 AM Jason Gunthorpe <jgg@xxxxxxxx> wrote:
>
> On Fri, Jun 13, 2025 at 04:58:27PM +0200, Pratyush Yadav wrote:
> > On Sat, Jun 07 2025, Pasha Tatashin wrote:
> > [...]
> > >>
> > >> This weirdness happens because luo_prepare() and luo_cancel() control
> > >> the KHO state machine, but then also get controlled by it via the
> > >> notifier callbacks. So the relationship between then is not clear.
> > >> __luo_prepare() at least needs access to struct kho_serialization, so it
> > >> needs to come from the callback. So I don't have a clear way to clean
> > >> this all up off the top of my head.
> > >
> > > On production machine, without KHO_DEBUGFS, only LUO can control KHO
> > > state, but if debugfs is enabled, KHO can be finalized manually, and
> > > in this case LUO transitions to prepared state. In both cases, the
> > > path is identical. The KHO debugfs path is only for
> > > developers/debugging purposes.
> >
> > What I meant is that even without KHO_DEBUGFS, LUO drives KHO, but then
> > KHO calls into LUO from the notifier, which makes the control flow
> > somewhat convoluted. If LUO is supposed to be the only thing that
> > interacts directly with KHO, maybe we should get rid of the notifier and
> > only let LUO drive things.
>
> Yes, we should. I think we should consider the KHO notifiers and self
> orchestration as obsoleted by LUO. That's why it was in debugfs
> because we were not ready to commit to it.

We could do that, however, there is one example KHO user
`reserve_mem`, that is also not liveupdate related. So, it should
either be removed or modified to be handled by LUO.

Mike, what do you think?

Pasha