From: Michael Kelley <redacted>
Sent: Friday, August 23, 2019 1:25 PM

From: Dexuan Cui Sent: Monday, August 19, 2019 6:52  PM

quoted

@@ -890,6 +937,11 @@ static void vmbus_onoffer(struct

vmbus_channel_message_header *hdr)
 				     false);
 		print_hex_dump_debug("New vmbus offer: ",

DUMP_PREFIX_OFFSET,

quoted

 				     16, 4, offer, offer_sz, false);
+
+		vmbus_setup_channel_state(oldchannel, offer);
+
+		check_ready_for_resume_event();

This is the error case where the new offer didn't match some aspect of
the old offer. 

Actually, this is not an error: besides the RELID, the host can also change
the offer->connection_id when it re-offers a device to the guest: so far,
I only see this host behavior for the VF vmbus device, and in this case, the
first vmbus_setup_channel_state() in vmbus_onoffer() is used to do the
fix-up:
    channel->sig_event = offer->connection_id;
and later channel->sig_event is used in vmbus_set_event().

Despite the host behavior, it looks the VF vmbus device still works fine,
so (IMO) this is not an error. I'll write a separate email to report this to
Hyper-V team.

Is the intent to proceed and use the new offer? 

Yes, since this is not an error.

I'll add a comment before the "Mismatched offer from the host" for this.

BTW, the 3 debug lines here output nothing, unless we enable the output
by 
  cd /sys/kernel/debug/dynamic_debug/
  echo 'file drivers/hv/channel_mgmt.c +p' > control
.

I can see that check_ready_for_resume_event() has to be called in
the error case, otherwise the resume operation will hang forever, but 
I'm not sure about setting up the channel state and then proceeding as
if all is good.

quoted

+
		return;

Thanks,
-- Dexuan