From: Dexuan Cui <[email protected]> Sent: Monday, July 8, 2019 10:29 PM
>
> When the VM resumes, the host re-sends the offers. We should not add the
> offers to the global vmbus_connection.chn_list again.
>
> Added some debug code, in case the host screws up the exact info related to
> the offers.
>
> Signed-off-by: Dexuan Cui <[email protected]>
> ---
> drivers/hv/channel_mgmt.c | 28 +++++++++++++++++++++++++++-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> index addcef5..a9aeeab 100644
> --- a/drivers/hv/channel_mgmt.c
> +++ b/drivers/hv/channel_mgmt.c
> @@ -854,12 +854,38 @@ void vmbus_initiate_unload(bool crash)
> static void vmbus_onoffer(struct vmbus_channel_message_header *hdr)
> {
> struct vmbus_channel_offer_channel *offer;
> - struct vmbus_channel *newchannel;
> + struct vmbus_channel *oldchannel, *newchannel;
> + size_t offer_sz;
>
> offer = (struct vmbus_channel_offer_channel *)hdr;
>
> trace_vmbus_onoffer(offer);
>
> + mutex_lock(&vmbus_connection.channel_mutex);
> + oldchannel = relid2channel(offer->child_relid);
> + mutex_unlock(&vmbus_connection.channel_mutex);
> +
> + 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? 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.
> +
> + 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.
> + return;
> + }
> +
> /* Allocate the channel object and save this offer. */
> newchannel = alloc_channel();
> if (!newchannel) {
> --
> 1.8.3.1
