From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Dmitry Fleytman <dmitry@daynix.com>,
Jason Wang <jasowang@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/4] e1000e: No need to validate configuration on migration
Date: Thu, 27 Oct 2016 13:22:29 +0100 [thread overview]
Message-ID: <20161027122228.GC2033@work-vm> (raw)
In-Reply-To: <20161027113909.GG5057@thinpad.lan.raisama.net>
* Eduardo Habkost (ehabkost@redhat.com) wrote:
> On Thu, Oct 27, 2016 at 09:42:53AM +0300, Dmitry Fleytman wrote:
> >
> > > On 26 Oct 2016, at 22:21 PM, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > >
> > > The user (or management software) is responsible for keeping the
> > > same configuration on both sides while migrating. Remove the
> > > configuration validation code at e1000e_post_load, and the
> > > unnecessary subsys_used/subsys_ven_used fields.
> >
> > Migration with different subsys/subsys_ven may have a
> > really cumbersome consequences that are very hard to debug,
> > so I believe such a verification may save a lot of time,
> > however it’s a matter of convention.
>
> The same issues apply to almost every other property on every
> other device. But the convention is to not expect devices to
> validate configuration changes on migration.
>
> (It would be nice to have a more generic mechanism that detects
> configuration mismatch on migration, though. Having each device
> manually checking each of its properties wouldn't work).
Without knowing the e1000e code, isn't the easy way to do this
to change the:
VMSTATE_UINT16(subsys, E1000EState),
VMSTATE_UINT16(subsys_ven, E1000EState),
to
VMSTATE_UINT16_EQUAL(subsys, E1000EState),
VMSTATE_UINT16_EQUAL(subsys_ven, E1000EState),
and the migration code will flag if they don't match for you.
Dave
>
> --
> Eduardo
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2016-10-27 12:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-26 19:21 [Qemu-devel] [PATCH 0/4] e1000e: QOM property & configuration cleanups Eduardo Habkost
2016-10-26 19:21 ` [Qemu-devel] [PATCH 1/4] e1000e: Use regular DEFINE_PROP_<type> macros for properties Eduardo Habkost
2016-10-27 3:12 ` Jason Wang
2016-10-27 6:38 ` Dmitry Fleytman
2016-10-27 11:25 ` Eduardo Habkost
2016-10-27 15:13 ` Igor Mammedov
2016-10-27 16:39 ` Eduardo Habkost
2016-10-26 19:21 ` [Qemu-devel] [PATCH 2/4] e1000e: No need to validate configuration on migration Eduardo Habkost
2016-10-27 6:42 ` Dmitry Fleytman
2016-10-27 11:39 ` Eduardo Habkost
2016-10-27 12:22 ` Dr. David Alan Gilbert [this message]
2016-10-27 14:28 ` Eduardo Habkost
2016-10-26 19:21 ` [Qemu-devel] [PATCH 3/4] e1000e: Rename "disable_vnet_hdr" property to "vnet" Eduardo Habkost
2016-10-27 6:47 ` Dmitry Fleytman
2016-10-26 19:21 ` [Qemu-devel] [PATCH 4/4] e1000e: Rename "subsys_ven" property to "subsys-vendor" Eduardo Habkost
2016-10-27 6:45 ` Dmitry Fleytman
2016-10-27 11:30 ` Eduardo Habkost
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=20161027122228.GC2033@work-vm \
--to=dgilbert@redhat.com \
--cc=dmitry@daynix.com \
--cc=ehabkost@redhat.com \
--cc=jasowang@redhat.com \
--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.