RE: [PATCH v3 12/12] Drivers: hv: vmbus: Resume after fixing up old primary channels

[Dexuan Cui]

> From: Michael Kelley <mikelley@xxxxxxxxxxxxx>
> Sent: Friday, August 23, 2019 1:25 PM
> 
> From: Dexuan Cui Sent: Monday, August 19, 2019 6:52  PM
> > @@ -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,
> >  				     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.
> > +
> > 		return;

Thanks,
-- Dexuan