Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757630AbcLOKgU (ORCPT ); Thu, 15 Dec 2016 05:36:20 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51756 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755573AbcLOKgS (ORCPT ); Thu, 15 Dec 2016 05:36:18 -0500 From: Vitaly Kuznetsov To: Olaf Hering 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 References: <20161207085110.GC1618@aepfle.de> Date: Thu, 15 Dec 2016 11:26:48 +0100 In-Reply-To: <20161207085110.GC1618@aepfle.de> (Olaf Hering's message of "Wed, 7 Dec 2016 09:51:10 +0100") Message-ID: <87r3594hef.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 15 Dec 2016 10:26:52 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1352 Lines: 36 Olaf Hering writes: > 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? Sorry guys I missed the discussion, I was on vacation. 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 CHANNELMSG_REQUESTOFFERS and on kdump we may not have this CPU up as we usually do kdump with nr_cpus=1 (and on the CPU which crashed). Minor issue is the necessity preserve the information about message/events pages across kexec. > > 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? > > Olaf > -- Vitaly