On Tue, Feb 3, 2015 at 11:30 AM, KY Srinivasan <kys@xxxxxxxxxxxxx>
wrote:
-----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, so you mean for other device, it won't get any interrupt before
guest negotiate the version with host?
Thanks
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
