From: KY Srinivasan <kys@microsoft.com>
To: Olaf Hering <olaf@aepfle.de>,
        "vkuznets@redhat.com" <vkuznets@redhat.com>
CC: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "devel@linuxdriverproject.org" <devel@linuxdriverproject.org>
Subject: RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel
Thread-Topic: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump
 kernel
Thread-Index: AQHSUGcX2rMR2fVQK0y/0wJ0y+Ek/aD8lNrQ
Date: Wed, 7 Dec 2016 15:04:29 +0000
Message-ID: <DM5PR03MB24907DE1957853FED1B87080A0850@DM5PR03MB2490.namprd03.prod.outlook.com>
References: <20161207085110.GC1618@aepfle.de>
In-Reply-To: <20161207085110.GC1618@aepfle.de>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2016 15:04:29.1674
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR03MB2492
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id uB7F4dlU028031
Content-Length: 1514
Lines: 37


> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Wednesday, December 7, 2016 12:51 AM
> To: KY Srinivasan <kys@microsoft.com>; vkuznets@redhat.com
> Cc: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org
> Subject: move hyperv CHANNELMSG_UNLOAD from crashed kernel to
> kdump kernel
> 
> KY,
> 
> if a hyperv VM crashes alot of work must be done to prepare the
> environment for the kdump kernel. This approach is different compared to
> all the other VM types, or baremetal. Since the just crashed kernel is
> per definition unreliable all that work should be done within the kdump
> kernel because I think a reliable environment exists only there.
> 
> Was it ever considered to do the CHANNELMSG_UNLOAD /
> CHANNELMSG_UNLOAD_RESPONSE work during boot, instead of doing it
> before
> starting the kexec/kdump kernel?
> 
> What would it take to prepare the runtime environment during boot?
> Does the newly booted kernel need any info from the previous kernel,
> something that cant be determined during boot? If yes, how can such info
> be passed from the old kernel to the new kernel?

Yes; I had played with this approach a while ago. The issue is that the host knows about a 
bunch of in memory state that will be different in the kexec kernel. For instance if we did all
the cleanup as part of the boot sequence, we will need access to all the interrupt/messaging 
infrastructure that was set up in the previous kernel.

K. Y
> 
> Olaf