> From: Michael Kelley <[email protected]>
> Sent: Tuesday, July 30, 2019 4:07 PM
> > +
> > + if (oldchannel != NULL) {
> > + atomic_dec(&vmbus_connection.offer_in_progress);
> > +
> > + /*
> > + * We're resuming from hibernation: we expect the host to send
> > + * exactly the same offers that we had before the hibernation.
> > + */
> > + offer_sz = sizeof(*offer);
> > + if (memcmp(offer, &oldchannel->offermsg, offer_sz) == 0)
> > + return;
>
> The offermsg contains "reserved" and "padding" fields. Does Hyper-V
> guarantee that all these fields are the same in the new offer after resuming
> from hibernation?
Yes. I confirmed this with Hyper-V team. The reserved/padding fields don't
change
across hiberantion. BTW, the fields are filled with zeros since they're not
used.
> Or should a less stringent check be made? For example,
> I could imagine a newer version of Hyper-V allowing a VM that was
> hibernated on an older version to be resumed. But one of the reserved fields
> might be used in the newer version, and the comparison could fail
> unnecessarily.
Upon resume, Linux VM always uses the same version, which was used when the
VM firstly booted up before suspend, to re-negotiate with the host.
> > +
> > + pr_err("Mismatched offer from the host (relid=%d)!\n",
> > + offer->child_relid);
> > +
> > + print_hex_dump_debug("Old vmbus offer: ", DUMP_PREFIX_OFFSET,
> 4,
> > + 4, &oldchannel->offermsg, offer_sz, false);
> > + print_hex_dump_debug("New vmbus offer: ",
> DUMP_PREFIX_OFFSET, 4,
> > + 4, offer, offer_sz, false);
>
> The third argument to print_hex_dump() is the rowsize and is specified as must
> be 16 or 32.
Thanks! I misunderstood the argument. I'll change it to 16.
Thanks,
-- Dexuan
