On 2025-10-19 10:15:19, Lukas Wunner wrote:
> On Sat, Oct 18, 2025 at 03:36:20PM -0700, Vipin Sharma wrote:
> > On 2025-10-18 09:17:33, Lukas Wunner wrote:
> > > On Fri, Oct 17, 2025 at 05:07:07PM -0700, Vipin Sharma wrote:
> > > > Move struct pci_saved_state{} and struct pci_cap_saved_data{} to
> > > > linux/pci.h so that they are available to code outside of the PCI core.
> > > >
> > > > These structs will be used in subsequent commits to serialize and
> > > > deserialize PCI state across Live Update.
> > >
> > > That's not sufficient as a justification to make these public in my view.
> > >
> > > There are already pci_store_saved_state() and pci_load_saved_state()
> > > helpers to serialize PCI state. Why do you need anything more?
> > > (Honest question.)
> >
> > In LUO ecosystem, currently, we do not have a solid solution to do
> > proper serialization/deserialization of structs along with versioning
> > between different kernel versions. This work is still being discussed.
> >
> > Here, I created separate structs (exactly same as the original one) to
> > have little bit control on what gets saved in serialized state and
> > correctly gets deserialized after kexec.
> >
> > For example, if I am using existing structs and not creating my own
> > structs then I cannot just do a blind memcpy() between whole of the PCI
> > state
> > prior to kexec to PCI state after the kexec. In the new kernel
> > layout might have changed like addition or removal of a field.
>
> The last time we changed those structs was in 2013 by fd0f7f73ca96.
> So changes are extremely rare.
>
> What could change in theory is the layout of the individual
> capabilities (the data[] in struct pci_cap_saved_data).
> E.g. maybe we decide that we need to save an additional register.
> But that's also rare. Normally we add all the mutable registers
> when a new capability is supported and have no need to amend that
> afterwards.
>
> So I think you're preparing for an eventuality that's very unlikely
> to happen. Question is whether that justifies the additional
> complexity and duplication. (Probably not.)
>
> Note that struct pci_cap_saved_state was made private in 2021 by
> f0ab00174eb7. We try to prevent other subsystems or drivers fiddling
> with structures internal to the PCI core. For LUO to find acceptance,
> it needs to respect subsystems' desire to keep private what's private
> and it needs to be as non-intrusive as possible. If necessary,
> helpers needed by LUO (e.g. to determine the size of saved PCI state)
> should probably live in the PCI core and be #ifdef'ed to LUO being enabled.
>
Sounds good, I will create helpers in PCI core and ifdef them for the
things we end up agreeing that need to be saved.
But I also think we need some guardrails to detect if they change
otherwise we might end up getting some hard to catch data corruption. I
think this ties up to what Jason also saying we need to define LUO ABI.
