From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935618AbcLOKhl (ORCPT ); Thu, 15 Dec 2016 05:37:41 -0500 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.216]:18370 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753800AbcLOKhi (ORCPT ); Thu, 15 Dec 2016 05:37:38 -0500 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi5z/J1IL7CYRxLEwpkY2XtLzyRUcY= X-RZG-CLASS-ID: mo00 Date: Thu, 15 Dec 2016 11:34:03 +0100 From: Olaf Hering To: Vitaly Kuznetsov Cc: kys@microsoft.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, devel@linuxdriverproject.org Subject: Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Message-ID: <20161215103402.GA6336@aepfle.de> References: <20161207085110.GC1618@aepfle.de> <87r3594hef.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <87r3594hef.fsf@vitty.brq.redhat.com> User-Agent: Mutt/1.7.2 (6888) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 15, Vitaly Kuznetsov wrote: > I see a number of minor but at least one major issue against such move: > At least for some Hyper-V versions (2012R2 for example) > CHANNELMSG_UNLOAD_RESPONSE is delivered to the CPU which initially sent= =20 > CHANNELMSG_REQUESTOFFERS and on kdump we may not have this CPU up as > we usually do kdump with nr_cpus=3D1 (and on the CPU which crashed).=20 Since the kdump or kexec kernel will send the unload during boot I would expect the response to arrive where it was sent, independent from the number of cpus. > Minor issue is the necessity preserve the information about > message/events pages across kexec. I guess this info is stored somewhere, and the relevant gfns can be preserved across kernels, if we try really hard. But after looking further at the involved code paths it seems that the implemnted polling might be good enough to snatch the response. Was the mdelay(10) just an arbitrary decision? I interpret the comments in vmbus_signal_eom such that the host may overwrite the response. Perhaps such thing may happen during the mdelay? Olaf --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSkRyP6Rn//f03pRUBdQqD6ppg2fgUCWFJxlwAKCRBdQqD6ppg2 fl81AJ9wtFRrKum0o60GZZRNLZyz/3/YZgCfeYuaQgTPFr6w6+BLug+n5rzueXk= =bRty -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS--