[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
- [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, (continued)
- [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, minyard, 2018/11/07
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Peter Maydell, 2018/11/08
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Corey Minyard, 2018/11/08
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Peter Maydell, 2018/11/08
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Corey Minyard, 2018/11/09
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Peter Maydell, 2018/11/09
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Corey Minyard, 2018/11/09
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Peter Maydell, 2018/11/09
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Dr. David Alan Gilbert, 2018/11/12
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom, Peter Maydell, 2018/11/12
- Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom,
Dr. David Alan Gilbert <=
[Qemu-devel] [PATCH 1/3] i2c:pm_smbus: Fix state transfer, minyard, 2018/11/07
[Qemu-devel] [PATCH 2/3] i2c: Add an SMBus vmstate structure, minyard, 2018/11/07