* Peter Maydell (peter.mayd...@linaro.org) wrote: > On 8 November 2018 at 17:58, Corey Minyard <cminy...@mvista.com> wrote: > > On 11/8/18 8:08 AM, Peter Maydell wrote: > >> This doesn't do anything for migration of the actual data contents. > >> The current users of this device (hw/arm/aspeed.c and the > >> smbus_eeprom_init() function) doesn't do anything > >> to migrate the contents. For that matter, "user of the device > >> passes a pointer to a random lump of memory via a device property" > >> is a bit funky as an interface. The device should allocate its > >> own memory and migrate it, and the user should just pass the > >> initial required contents (default being "zero-initialize", > >> which is what everybody except the mips_fulong2e, mips_malta > >> and sam460ex want). > > > I debated on this, and it depends on what the eeprom is used for. If > > it's a DRAM eeprom, it shouldn't need to be transferred. > > It's guest-visible data; the guest can write it and read it back. > So it needs to be migrated. Otherwise behaviour after migration > will not be the same as if the guest had never migrated. > > >> Does this also break migration from an old QEMU to a new one? > >> (For Aspeed that's probably ok, but we should flag it up in the > >> commit message if so. x86 uses need care...) > >> > > There is no transfer before, so I don't see why it would break anything. > > Am I missing something? > > I forget what the behaviour is where the source QEMU didn't > have a vmstate at all but the destination QEMU does expect > one. David can remind me...
If it's a separate device then you tend to get away with it - there's no check that all devices receive their state, so it should work. This does break backwards migration though - migrating to an older qemu with the existing machine type will complain it's received a device which it doesn't understand. You should be able to add a .needed to the device so it's only sent for new machine types. (Which is what I said in August, when I also asked about the data) Dave > thanks > - PMM -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK