RE: [PATCH 5/7] Drivers: hv: vmbus: Ignore the offers when resuming from hibernation

[Dexuan Cui <decui@microsoft.com>]

> From: Michael Kelley <mikelley@microsoft.com>
> 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