RE: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a later place

From: KY Srinivasan
Date: Mon Feb 02 2015 - 22:45:16 EST




> -----Original Message-----
> From: Jason Wang [mailto:jasowang@xxxxxxxxxx]
> Sent: Monday, February 2, 2015 7:09 PM
> To: Dexuan Cui
> Cc: gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; driverdev-
> devel@xxxxxxxxxxxxxxxxxxxxxx; olaf@xxxxxxxxx; apw@xxxxxxxxxxxxx; KY
> Srinivasan; vkuznets@xxxxxxxxxx; Haiyang Zhang
> Subject: RE: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a later place
>
>
>
> On Mon, Feb 2, 2015 at 6:09 PM, Dexuan Cui <decui@xxxxxxxxxxxxx> wrote:
> >> -----Original Message-----
> >> From: Jason Wang [mailto:jasowang@xxxxxxxxxx]
> >> Sent: Monday, February 2, 2015 17:36 PM
> >> To: Dexuan Cui
> >> Cc: gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> >> driverdev-
> >> devel@xxxxxxxxxxxxxxxxxxxxxx; olaf@xxxxxxxxx; apw@xxxxxxxxxxxxx; KY
> >> Srinivasan; vkuznets@xxxxxxxxxx; Haiyang Zhang
> >> Subject: Re: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a
> >> later place
> >>
> >>
> >>
> >> On Mon, Feb 2, 2015 at 12:35 PM, Dexuan Cui <decui@xxxxxxxxxxxxx>
> >> wrote:
> >> > Before the line vmbus_open() returns, srv->util_cb can be already
> >> > running > and the variables, like util_fw_version, are needed by
> >> the > srv->util_cb.
> >>
> >> A questions is why we do this for util only? Can callbacks of other
> >> devices be called before vmbus_open() returns?
> > The variables are used in vmbus_prep_negotiate_resp(), which is only
> > for the util devices.
> >
> > I think the other devices should already handle the similar issue
> > properly.
> > If this is not the case, we need to fix them too.
>
> Better to check all the others, e.g in balloon_probe(), it call
> hv_set_drvdata() after vmbus_open() and dose several datas setups in the
> middle. If balloon_onchannelcallback() could be called before
> hv_set_drvdata(), the code looks wrong.

Jason,

For all other device types, the guest initiates the communication with the host and potentially
negotiates appropriate (supported) version with the host. For the services packaged in the util
driver, the flow is a little different - the host pushes the version information into the guest. So,
the fix Dexuan made is only needed in the util driver.

Regards,

K. Y
>
> Thanks
>
>