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

[Greg Kroah-Hartman]

On Mon, Jan 26, 2015 at 11:38:54AM +0100, Vitaly Kuznetsov wrote:
> 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 ...

This is a trivial number of patches for this subsystem, so no, a git
workflow isn't needed.  But if KY would collect the patches up and send
them to me for all hyperv patches from now on, that would make these
types of issues go away, KY, can you do that from now on?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/