On Mon, 26 Oct 2026 at 17:39, Peter Xu <[email protected]> wrote: > > On Mon, Oct 26, 2026 at 12:19:07PM -0400, Michael S. Tsirkin wrote: > > On Mon, Oct 26, 2026 at 04:11:57PM +0000, Peter Maydell wrote: > > > In reviewing a new pcie host bridge, I noticed (because this new device > > > copied existing code) that the vmstate structs for pcie root ports do > > > this in their vmstate structs: > > > > > > .fields = (const VMStateField[]) { > > > VMSTATE_PCI_DEVICE(parent_obj.parent_obj.parent_obj, PCIESlot), > > > VMSTATE_STRUCT(parent_obj.parent_obj.parent_obj.exp.aer_log, > > > PCIESlot, 0, vmstate_pcie_aer_log, PCIEAERLog), > > > VMSTATE_MSIX(parent_obj.parent_obj.parent_obj.parent_obj, > > > GenPCIERootPort), > > > VMSTATE_END_OF_LIST() > > > } > > > > > > (this specific example is hw/pci-bridge/gen_pcie_root_port.c). > > > > > > Devices shouldn't have to have ugly long chains of "parent_obj" > > > like this and shouldn't have to care what in their parents needs > > > migration; compare e.g. SCSI devices, which start with a > > > "VMSTATE_SCSI_DEVICE" that captures all the parent class's needs, > > > followed by only the state that the child added. > > > > > > How can we get to something more like that for PCIE port classes? > > > > > > thanks > > > -- PMM > > > > Yea makes total sense. Anyone has the bandwidth to take a stab? > > I'm buried under a pile of ai generated security reports. > > /me buried too on other things downstream. I'm prepared to not be able to > work much upstream until after forum.. > > A quick look is this is not too bad yet: > > $ git grep parent_obj.parent_obj | wc -l > 20 > $ git grep parent_obj.parent_obj.parent_obj | wc -l > 11 > (and, some of above lines are part of vm static checker script) > > Looks not too bad yet?
Depends on your definition of "bad" :-) This is basically the only vmstate that's doing this thing, and it would be nice to correct it before we add more devices that end up following the same pattern. I agree it's not super urgent; I posted mostly because I have no idea what the right fix is (especially given we want to retain migration compat here). thanks -- PMM
