> From: Michael Kelley <mikelley@xxxxxxxxxxxxx> > 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