From: KY Srinivasan <kys@microsoft.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
CC: "devel@linuxdriverproject.org" <devel@linuxdriverproject.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Haiyang Zhang <haiyangz@microsoft.com>,
        "Alex Ng (LIS)" <alexng@microsoft.com>,
        "Radim Krcmar" <rkrcmar@redhat.com>, Cathy Avery <cavery@redhat.com>
Subject: RE: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
Thread-Topic: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
Thread-Index: AQHRgRJgH+GbSkQfjk2MKtlbBA5OMZ9ffm9ggAQMh/yAAOv38IABDXtVgAAEcwA=
Date: Tue, 22 Mar 2016 14:18:05 +0000
Message-ID: <SN2PR03MB2142A6D723E95FCE7193CFE4A0800@SN2PR03MB2142.namprd03.prod.outlook.com>
References: <1458304404-8347-1-git-send-email-vkuznets@redhat.com>
	<SN2PR03MB214246D9A9DAFA36E392AE78A08C0@SN2PR03MB2142.namprd03.prod.outlook.com>
	<874mc02rqd.fsf@vitty.brq.redhat.com>
	<SN2PR03MB214219E2FCCA0B1FD176A27BA08F0@SN2PR03MB2142.namprd03.prod.outlook.com>
 <87mvpq7gtg.fsf@vitty.brq.redhat.com>
In-Reply-To: <87mvpq7gtg.fsf@vitty.brq.redhat.com>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2016 14:18:06.0014
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2142
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3608
Lines: 93


> -----Original Message-----
> From: Vitaly Kuznetsov [mailto:vkuznets@redhat.com]
> Sent: Tuesday, March 22, 2016 7:01 AM
> To: KY Srinivasan <kys@microsoft.com>
> Cc: devel@linuxdriverproject.org; linux-kernel@vger.kernel.org; Haiyang
> Zhang <haiyangz@microsoft.com>; Alex Ng (LIS) <alexng@microsoft.com>;
> Radim Krcmar <rkrcmar@redhat.com>; Cathy Avery <cavery@redhat.com>
> Subject: Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
> 
> KY Srinivasan <kys@microsoft.com> writes:
> 
> >> -----Original Message-----
> >> From: Vitaly Kuznetsov [mailto:vkuznets@redhat.com]
> >> Sent: Monday, March 21, 2016 12:52 AM
> >> To: KY Srinivasan <kys@microsoft.com>
> >> Cc: devel@linuxdriverproject.org; linux-kernel@vger.kernel.org; Haiyang
> >> Zhang <haiyangz@microsoft.com>; Alex Ng (LIS)
> <alexng@microsoft.com>;
> >> Radim Krcmar <rkrcmar@redhat.com>; Cathy Avery
> <cavery@redhat.com>
> >> Subject: Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
> >>
> >> KY Srinivasan <kys@microsoft.com> writes:
> >>
> >> >> -----Original Message-----
> >> >> From: Vitaly Kuznetsov [mailto:vkuznets@redhat.com]
> >> >> Sent: Friday, March 18, 2016 5:33 AM
> >> >> To: devel@linuxdriverproject.org
> >> >> Cc: linux-kernel@vger.kernel.org; KY Srinivasan <kys@microsoft.com>;
> >> >> Haiyang Zhang <haiyangz@microsoft.com>; Alex Ng (LIS)
> >> >> <alexng@microsoft.com>; Radim Krcmar <rkrcmar@redhat.com>;
> Cathy
> >> >> Avery <cavery@redhat.com>
> >> >> Subject: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
> >> >>
> >> >> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is
> >> always
> >> >> delivered to CPU0 regardless of what CPU we're sending
> >> >> CHANNELMSG_UNLOAD
> >> >> from. vmbus_wait_for_unload() doesn't account for the fact that in
> case
> >> >> we're crashing on some other CPU and CPU0 is still alive and
> operational
> >> >> CHANNELMSG_UNLOAD_RESPONSE will be delivered there
> completing
> >> >> vmbus_connection.unload_event, our wait on the current CPU will
> never
> >> >> end.
> >> >
> >> > What was the host you were testing on?
> >> >
> >>
> >> I was testing on both 2012R2 and 2016TP4. The bug is easily reproducible
> >> by forcing crash on a secondary CPU, e.g.:
> >
> > Prior to 2012R2, all messages would be delivered on CPU0 and this includes
> CHANNELMSG_UNLOAD_RESPONSE.
> > For this reason we don't support kexec on pre-2012 R2 hosts. On 2012.
> From 2012 R2 on, all vmbus
> > messages (responses) will be delivered on  the CPU that we initially set up -
> look at the code in
> > vmbus_negotiate_version(). So on post 2012 R2 hosts, the response to
> CHANNELMSG_UNLOAD_RESPONSE
> > will be delivered on the CPU where we initiate the contact with the
> > host - CHANNELMSG_INITIATE_CONTACT message.
> 
> Unfortunatelly there is a descrepancy between WS2012R2 and WS2016TP4.
> On
> WS2012R2 what you're saying is true and all messages including
> CHANNELMSG_UNLOAD_RESPONSE are delivered to the CPU we used for
> initial
> contact. On WS2016TP4 CHANNELMSG_UNLOAD_RESPONSE seems to be a
> special
> case and it is always delivered to CPU0, no matter which CPU we used for
> initial contact. This can be a host bug. You can use the attached patch
> to see the issue.

This looks like a host bug and I will try to get is addressed before ws2016
ships.
> 
> For now I can suggest we check message pages for all CPUs from
> vmbus_wait_for_unload(). We can race with other CPUs again but we don't
> care as we're checking for completion_done() in the loop as well. I'll
> try this approach.
Thank you.

K. Y

> 
> --
>   Vitaly