qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eepr


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom
Date: Mon, 12 Nov 2018 17:28:42 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

* Peter Maydell (address@hidden) wrote:
> On 8 November 2018 at 17:58, Corey Minyard <address@hidden> 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 / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]