From: Stefan Hajnoczi <stefanha@redhat.com>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: Edgar Iglesias <edgar.iglesias@xilinx.com>,
Peter Maydell <peter.maydell@linaro.org>,
Juan Quintela <quintela@redhat.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Beniamino Galvani <b.galvani@gmail.com>,
Li Guang <lig.fnst@cn.fujitsu.com>
Subject: Re: [Qemu-devel] [PATCH v2 1/2] hw/net: add support for Allwinner EMAC Fast Ethernet controller
Date: Thu, 16 Jan 2014 10:45:11 +0800 [thread overview]
Message-ID: <20140116024511.GA11535@stefanha-thinkpad> (raw)
In-Reply-To: <CAEgOgz6cR06LRLwy24m0rj+eZEh9tfa5YsD0+wTM6JsWHpgFuA@mail.gmail.com>
On Wed, Jan 15, 2014 at 06:24:24PM +1000, Peter Crosthwaite wrote:
> On Tue, Jan 14, 2014 at 3:19 PM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> > On Mon, Jan 13, 2014 at 11:16:37PM +1000, Peter Crosthwaite wrote:
> >> On Mon, Jan 13, 2014 at 11:15 PM, Peter Crosthwaite
> >> <peter.crosthwaite@xilinx.com> wrote:
> >> > On Sat, Jan 11, 2014 at 8:13 PM, Beniamino Galvani <b.galvani@gmail.com> wrote:
> >> >> +static const VMStateDescription vmstate_mii = {
> >> >> + .name = "allwinner_emac_mii",
> >> >> + .version_id = 1,
> >> >> + .minimum_version_id = 1,
> >> >> + .fields = (VMStateField[]) {
> >> >> + VMSTATE_UINT16(bmcr, AwEmacMii),
> >> >> + VMSTATE_UINT16(bmsr, AwEmacMii),
> >> >> + VMSTATE_UINT16(anar, AwEmacMii),
> >> >> + VMSTATE_UINT16(anlpar, AwEmacMii),
> >> >> + VMSTATE_BOOL(link_ok, AwEmacMii),
> >> >
> >> > The net layer should probably properly set link_ok on realize, so I
> >> > doubt it's migratable state.
> >
> > The net layer is not part of live migration. It's up to the emulated
> > device to migrate link state and restore it after migration. In other
> > words, link state should be migrated as part of PHY vmstate.
> >
>
> But is the saved link state meaningful? The fact that net is not
> migrating means that this link_ok migrated variable is potentially
> incoherent with the net layer. E.G. What happens in the following
> case:
>
> Run QEMU
> Link is Good
> Save
>
> Run Again
> Link is bad
> Load
>
> The loaded emulation will have link_ok due to the vmsd load despite
> the link being down in the new net layer environment. It will not
> correct until net-layer activity causes a ->link_state_changed
> callback.
I would agrue that this example is not valid. NetClient->link_down is
influenced by two things:
1. User actions that disable the link (e.g. setting link status)
2. Backends may take the link down, e.g. if the net/socket.c connection
breaks.
In either case, the guest should migrate with its original link status.
Then, when it resumes on the destination host the link state may change
or an interrupt can be raised.
> Can this be just solved cleanly by calling the mii_set_link fn (added
> in this patch) always on post load and removing this link_ok state?
> This will mean that guest will see a link state transition immediately
> on load if the link state changes from the saved-machine state to the
> loaded-machine state.
Is the link_ok field even necessary? Perhaps we should just rely on
NetClient->link_ok.
next prev parent reply other threads:[~2014-01-16 6:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-11 10:13 [Qemu-devel] [PATCH v2 0/2] hw/arm: add ethernet support to Allwinner A10 Beniamino Galvani
2014-01-11 10:13 ` [Qemu-devel] [PATCH v2 1/2] hw/net: add support for Allwinner EMAC Fast Ethernet controller Beniamino Galvani
2014-01-13 5:20 ` Stefan Hajnoczi
2014-01-13 13:15 ` Peter Crosthwaite
2014-01-13 13:16 ` Peter Crosthwaite
2014-01-14 5:19 ` Stefan Hajnoczi
2014-01-15 8:24 ` Peter Crosthwaite
2014-01-15 10:25 ` Juan Quintela
2014-01-15 12:15 ` Peter Crosthwaite
2014-01-16 2:45 ` Stefan Hajnoczi [this message]
2014-01-16 12:52 ` Peter Crosthwaite
2014-01-17 3:25 ` Stefan Hajnoczi
2014-01-15 12:40 ` Peter Crosthwaite
2014-01-15 21:42 ` Beniamino Galvani
2014-01-15 23:29 ` Peter Crosthwaite
2014-01-11 10:13 ` [Qemu-devel] [PATCH v2 2/2] hw/arm/allwinner-a10: initialize EMAC Beniamino Galvani
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=20140116024511.GA11535@stefanha-thinkpad \
--to=stefanha@redhat.com \
--cc=b.galvani@gmail.com \
--cc=edgar.iglesias@xilinx.com \
--cc=lig.fnst@cn.fujitsu.com \
--cc=peter.crosthwaite@xilinx.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).