From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Corey Minyard <cminyard@mvista.com>,
Corey Minyard <minyard@acm.org>,
QEMU Developers <qemu-devel@nongnu.org>,
Paolo Bonzini <pbonzini@redhat.com>,
"Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom
Date: Mon, 12 Nov 2018 17:28:42 +0000 [thread overview]
Message-ID: <20181112172842.GG2293@work-vm> (raw)
In-Reply-To: <CAFEAcA9D4=KgmGqJbUceD_bxO11CBTDH7G3-54kn25nfi1XPJA@mail.gmail.com>
* Peter Maydell (peter.maydell@linaro.org) wrote:
> On 8 November 2018 at 17:58, Corey Minyard <cminyard@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 / dgilbert@redhat.com / Manchester, UK
prev parent reply other threads:[~2018-11-12 17:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-07 15:54 [Qemu-devel] [PATCH 0/3] Fix/add vmstate handling in some I2C code minyard
2018-11-07 15:54 ` [Qemu-devel] [PATCH 1/3] i2c:pm_smbus: Fix state transfer minyard
2018-11-12 17:47 ` Dr. David Alan Gilbert
2018-11-12 20:32 ` Corey Minyard
2018-11-07 15:54 ` [Qemu-devel] [PATCH 2/3] i2c: Add an SMBus vmstate structure minyard
2018-11-08 14:23 ` Philippe Mathieu-Daudé
2018-11-08 14:40 ` Peter Maydell
2018-11-08 14:48 ` Philippe Mathieu-Daudé
2018-11-07 15:54 ` [Qemu-devel] [PATCH 3/3] i2c: Add vmstate handling to the smbus eeprom minyard
2018-11-08 14:08 ` Peter Maydell
2018-11-08 17:58 ` Corey Minyard
2018-11-08 18:03 ` Peter Maydell
2018-11-09 14:56 ` Corey Minyard
2018-11-09 15:02 ` Peter Maydell
2018-11-09 17:19 ` Corey Minyard
2018-11-09 17:53 ` Peter Maydell
2018-11-12 17:38 ` Dr. David Alan Gilbert
2018-11-12 17:41 ` Peter Maydell
2018-11-12 17:28 ` Dr. David Alan Gilbert [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181112172842.GG2293@work-vm \
--to=dgilbert@redhat.com \
--cc=cminyard@mvista.com \
--cc=minyard@acm.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.