On Tue, Mar 27, 2018 at 7:26 AM, Dr. David Alan Gilbert <dgilb...@redhat.com> wrote: > 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.
Right. > 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? The best we can do is copy the old props into both props and tso_props. Copying it into just props means that e1000 would suddenly find all zero offsets in tso_props, screwing up an ongoing TCP session using TSO in a Windows guest. Conversely copying into just tso_props would screw up an ongoing UDP session using non-TSO offload in a Windows guest. Copying means we do no worse than the buggy 2.11 behavior, until both TSO and non-TSO contexts are refreshed and everything is fine. (For Linux guests it doesn't matter since Linux always seems to refresh both TSO and non-TSO contexts before every tx data descriptor.) > 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? This case is trickier. We want to copy into the old props whichever one of props and tso_props was updated most recently by a non-TSO or TSO context descriptor. Always copying one or the other risks screwing up an ongoing session in a Windows guest by using outdated offsets. (Again there's no problem for Linux guests.) Probably the easiest solution is to add yet another flag (which doesn't itself get migrated) that's set when tso_props is updated and cleared when props is updated. > 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? This is the same as (b) I think. --Ed
