* Peter Maydell (peter.mayd...@linaro.org) wrote: > On Thu, 8 Aug 2019 at 16:42, Dr. David Alan Gilbert <dgilb...@redhat.com> > wrote: > > > > * Peter Maydell (peter.mayd...@linaro.org) wrote: > > > On Mon, 29 Jul 2019 at 15:59, Damien Hedde <damien.he...@greensocs.com> > > > wrote: > > > > > > > > This add the reset related sections for every QOM > > > > device. > > > > > > A bit more detail in the commit message would help, I think -- > > > this is adding extra machinery which has to copy and modify > > > the VMStateDescription passed in by the device in order to > > > add the subsection that handles reset. > > > > > > I've added Dave Gilbert to the already long cc list since this > > > is migration related. > > > > I don't like dynamically modifying all the vmsds. > > Yeah, I'm not a huge fan of it either, but it does mean that > the state gets migrated and we don't have a pile of really > easy to miss bugs where we forgot to say "this device needs to > migrate the reset state" and it means we don't have every > device we ever write in the future needing to say "this device > needs to migrate reset state"... > > > Aren't you going to have to understand each devices reset behaviour > > and make sure it does something sane? e.g. it might have a postload > > that registers a timer or something that you wouldn't want to do if it's > > in reset. > > > > The easiest way is to write a macro that you can easily add to devices > > you've checked subsection list (like the way we have a > > VMSTATE_USB_DEVICE). > > One problem is that as soon as somebody writes a USB controller > or PCI controller model that can be held in reset, every > device that could sat behind it automatically now could find > that it's migrated while it's in reset.
I'm not convinced though that they'll all be fixed by adding this subsection; I think some of those devices you're going to have to look at and see what they do. Dave > thanks > -- PMM -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
