Re: [PATCH v3] Drivers: hv: vmbus: prevent cpu offlining on newer hypervisors

[Vitaly Kuznetsov]

 Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> writes:

> On Mon, Jan 12, 2015 at 05:50:11PM +0100, Vitaly Kuznetsov wrote:
>> When an SMP Hyper-V guest is running on top of 2012R2 Server and secondary
>> cpus are sent offline (with echo 0 > /sys/devices/system/cpu/cpu$cpu/online)
>> the system freeze is observed. This happens due to the fact that on newer
>> hypervisors (Win8, WS2012R2, ...) vmbus channel handlers are distributed
>> across all cpus (see init_vp_index() function in drivers/hv/channel_mgmt.c)
>> and on cpu offlining nobody reassigns them to CPU0. Prevent cpu offlining
>> when vmbus is loaded until the issue is fixed host-side.
>> 
>> This patch also disables hibernation but it is OK as it is also broken (MCE
>> error is hit on resume). Suspend still works.
>> 
>> Tested with WS2008R2 and WS2012R2.
>> 
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
>> Signed-off-by: K. Y. Srinivasan <kys@xxxxxxxxxxxxx>
>> ---
>> Changes since v2:
>> - repair the build when vmbus is builded as a module [Greg KH] by saving
>>   current cpu_disable pointer to previous_cpu_disable and restoring it on
>>   unload;
>> - return -ENOSYS (same as native_cpu_disable when !CONFIG_HOTPLUG_CPU) instead
>>   of -1 in hyperv_cpu_disable().
>> 
>> Changes since v1:
>> - introduce hv_cpu_hotplug_quirk() function to not spread #ifdefs [Greg KH];
>> - add pr_notice() message "hv_vmbus: CPU offlining is not supported by
>>   hypervisor".
>> ---
>>  drivers/hv/vmbus_drv.c | 36 ++++++++++++++++++++++++++++++++++++
>>  1 file changed, 36 insertions(+)
>
> Doesn't apply to my char-misc-test branch at all :(

Another mid-air collision with K.Y's "Drivers: hv: vmbus: Implement a
clockevent device", please use the attached version. No functional
changes are required, I just fixed the merge conflict (includes).

Othere than that (and sorry for meddling), would it it be better if
you switch to 'pull requests' workflow with K.Y? There is a lot of
ongoing work in hyperv nowdays and such collisions seem otherwise
inevitable ...

-- 
  Vitaly