All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, eswierk@skyportsystems.com,
	jasowang@redhat.com, peterx@redhat.com, quintela@redhat.com
Subject: Re: [Qemu-devel] [PATCH 3/3] e1000: Old machine types, turn new subsection off
Date: Tue, 27 Mar 2018 19:01:16 +0100	[thread overview]
Message-ID: <20180327180115.GH2837@work-vm> (raw)
In-Reply-To: <8c238385-5cab-2c7d-6550-d6d0866570eb@redhat.com>

* Paolo Bonzini (pbonzini@redhat.com) wrote:
> On 27/03/2018 18:47, Dr. David Alan Gilbert wrote:
> >> So if the subsection is absent you
> >> have to migrate either tx.tso_props or tx.props, depending on s->tx.cptse.
> > Do you mean when sending you have to decide which set to send in the
> > non-subsection data?  And with cptse true that means use tso_props?
> 
> Yes.
> 
> >> Likewise if you migrate from older versions: if s->tx.props.tse &&
> >> s->tx.cptse, you have to copy s->tx.props to s->tx.tso_props and clear
> >> s->tx.props.
> > 
> > I don't see any equivalent code in the existing non-subsection postload to
> > do this; so I'm guessing there are some cases of 2.11->2.12 that will
> > break at the moment?
> 
> Yes, I think so.

OK, so we'd better fix that for 2.12.

> >> My understanding is that s->tx.tso_props.tse will be 1 if
> >> and only if the source sent s->tx.tso_props.
> > I don't see anything in the current code that migrates tso_props.tse -
> > where does it come from?
> 
> Ouch... The tse field is more or less dead in current code AFAICS, but
> it was used in the previous version.  What's the best way then to find
> if the subsection was transmitted?  Do we have anything like a post_load
> callback in the subsection itself?

Yes, if I just add a .post_load field in the subsection it should get
called.

> To find out which "props" to transmit to older QEMU, you can add a
> tp->use_tso_for_migration = tp->cptse just before "if (!(txd_lower &
> E1000_TXD_CMD_EOP))" in process_tx_desc...

OK.

> >> This seems most easily done with a new field (e.g. vmstate_fixed_props)
> >> that is written in pre_save and set in post_load.
> > It might need a VMSTATE_WITH_TMP to be able to do the saving part;
> > when saving we can't change the current state when migrating
> > to an old destination in case the migration fails and we just continue.
> 
> Perhaps you can just copy props/tso_props to a new field, and change all the
> 
>         VMSTATE_UINT8(tx.props.ipcss, E1000State),
>         VMSTATE_UINT8(tx.props.ipcso, E1000State),
>         VMSTATE_UINT16(tx.props.ipcse, E1000State),
> 
> to
> 
>         VMSTATE_UINT8(tx_legacy_vmstate_props.ipcss, E1000State),
> 	...
> 
> and then add tx.props to the subsection together with tso.props.
> 
> New->old migration will place tx_legacy_vmstate_props in tx.props on the
> destination; new->new will realize the subsection was transmitted and
> ignore the tx_legacy_vmstate_props; old->new will not find data from the
> subsection and copy the tx_legacy_vmstate_props into one of tx.props and
> tx.tso_props.

Yeh, adding a legacy_props field should do it; although we never need
to transmit more than 2 copies.  

I'll look at this more tomorrow; I am a bit worried about testing it
though.

Dave


> Paolo
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2018-03-27 18:01 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 [this message]
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
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=20180327180115.GH2837@work-vm \
    --to=dgilbert@redhat.com \
    --cc=eswierk@skyportsystems.com \
    --cc=jasowang@redhat.com \
    --cc=pbonzini@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 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.