On Fri, 23 Oct 2026 at 14:59, Marcelo Manzo <[email protected]> wrote: > > This series gets raspi4b's PCIe root complex and GENET Ethernet > controller working end to end: the PCIe link comes up and devices on > it enumerate, and GENET passes real network traffic (DHCP, SSH, bulk > downloads) under both older (Debian 11, 5.15) and newer (Debian 13, > 6.18) guest kernels. Most of the GENET code is Sergey Kambalin's > 2024 series (patchwork series 829638), carried forward with his > authorship and Signed-off-by kept. > > v5: thanks to Peter for the review of v4.
> - Dropped v4 patch 14 (GENET migration state): migration state for > the GENET device was not asked for in review, and the points made > on it (no post_load function is needed, and > VMSTATE_BUFFER_UNSAFE is not right for registers) mean it would > have to describe every register field by field. The series > therefore no longer adds migration state for GENET; the root port > keeps its vmstate from patch 1. I asked you not to implement migration wrongly; I didn't say you could skip it. As a general baseline, all new QEMU devices should implement migration unless they have a good reason (e.g. they are explicitly experimental) and they set up a migration-blocker explaining why. For this device migration is not complicated to implement, and so I think we should just do it. More generally: * you can implement device state as an array of uint32_t, and get the benefit of e.g. migration and default-read/write codepaths being more concise, with the downside of having to write s->regs[R_FOO] instead of s->foo * or you can implement device state as a set of fields, and get nice-looking s->foo access within the implementation at the cost of needing a switch case and a VMSTATE macro per field But you don't get to implement device state as a set of fields and then say "but I won't do the parts that that approach makes a pain". thanks -- PMM
