qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: qemu-devel@nongnu.org, eswierk@skyportsystems.com,
	quintela@redhat.com, peterx@redhat.com
Subject: Re: [Qemu-devel] [PATCH 0/3] e1000 migration changes for 2.12
Date: Tue, 27 Mar 2018 15:26:13 +0100	[thread overview]
Message-ID: <20180327142610.GC2837@work-vm> (raw)
In-Reply-To: <0cb312f6-6c36-25ac-3c9a-0d9626abac56@redhat.com>

* Jason Wang (jasowang@redhat.com) wrote:
> 
> 
> On 2018年03月27日 19:34, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > 
> > Hi Ed, Jason,
> >    This set of patches change the e1000 migration code to make
> > it easier to keep with compatibility with older versions in backwards
> > migration;  but I do need some advice whether I need to do more as well.
> > 
> > I think the first and second patch are fairly uncontrovercial and I
> > would like them for 2.12, since it'll make any future changes easier.
> > The third one changes the default behaviour, so again I'd prefer it but
> > lets see what you think.
> 
> The patches looks good to me. So for the changes of default behavior, did
> you mean we can make the migration to older versions work?

Right.

> > My question however, without knowing the internals of the e1000, is
> > whether when ommitting the subsection, should the code in 2.12 be
> > changing the data it sends back in the main section of data?
> 
> I'm not sure I get the meaning here. But it looks to me turning it off for
> old machine types makes sense, otherwise, management need to set it
> explicitly.

OK, let me expand the question a bit.
If I understand correctly the d6244b description, there's two pieces of
state (TSO and non-TSO) where there used to be only one.
Now, with the new format we migrate both pieces of state, but lets think
about what happens if we have to migrate only one piece.

a) 2.11->2.11 migrated the only piece it knew about; so I guess the only
problem was really the UDP corruption mentioned in the commit.

b) 2.11->2.12 - it receives the wrongly merged piece of state and puts it
in - well which of the two states does it load it into?  What's the
effect of that?

c) 2.12(+my mod)->2.11 ok, so 2.12 will have filled in both sets of state
internally; but now it's only going to send one of them over to 2.11 -
which one gets sent to 2.11? Is it the one that 2.11 is expecting?

d) 2.12(+my mod)->2.12(+my mod) with an old machine type, again we're only
going to send one set of data (same as c) - but what's 2.12 going to
make of the one piece of state received?

(b) is an existing question.

Dave

> Thanks
> 
> > 
> > Dave
> > 
> > 
> > Dr. David Alan Gilbert (3):
> >    e1000: Convert v3 fields to subsection
> >    e1000: wire new subsection to property
> >    e1000: Old machine types, turn new subsection off
> > 
> >   hw/net/e1000.c      | 46 ++++++++++++++++++++++++++++++++++------------
> >   include/hw/compat.h |  4 ++++
> >   2 files changed, 38 insertions(+), 12 deletions(-)
> > 
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2018-03-27 14:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-27 11:34 [Qemu-devel] [PATCH 0/3] e1000 migration changes for 2.12 Dr. David Alan Gilbert (git)
2018-03-27 11:34 ` [Qemu-devel] [PATCH 1/3] e1000: Convert v3 fields to subsection Dr. David Alan Gilbert (git)
2018-03-27 11:34 ` [Qemu-devel] [PATCH 2/3] e1000: wire new subsection to property Dr. David Alan Gilbert (git)
2018-03-27 11:34 ` [Qemu-devel] [PATCH 3/3] e1000: Old machine types, turn new subsection off Dr. David Alan Gilbert (git)
2018-03-27 16:07   ` Paolo Bonzini
2018-03-27 16:47     ` Dr. David Alan Gilbert
2018-03-27 17:28       ` Paolo Bonzini
2018-03-27 18:01         ` Dr. David Alan Gilbert
2018-03-27 20:17           ` Paolo Bonzini
2018-03-28  0:31         ` Ed Swierk
2018-03-27 13:06 ` [Qemu-devel] [PATCH 0/3] e1000 migration changes for 2.12 Jason Wang
2018-03-27 14:26   ` Dr. David Alan Gilbert [this message]
2018-03-27 23:53     ` Ed Swierk
2018-03-28  2:45     ` Jason Wang
2018-03-27 14:06 ` Juan Quintela

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=20180327142610.GC2837@work-vm \
    --to=dgilbert@redhat.com \
    --cc=eswierk@skyportsystems.com \
    --cc=jasowang@redhat.com \
    --cc=peterx@redhat.com \
    --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).