Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 5 Jan 2021 13:04:23 +0000
From:   Wei Liu <wei.liu@kernel.org>
To:     Dexuan Cui <decui@microsoft.com>
Cc:     tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org,
        hpa@zytor.com, linux-hyperv@vger.kernel.org,
        mikelley@microsoft.com, wei.liu@kernel.org, vkuznets@redhat.com,
        jwiesner@suse.com, ohering@suse.com, linux-kernel@vger.kernel.org,
        sthemmin@microsoft.com, haiyangz@microsoft.com, kys@microsoft.com
Subject: Re: [PATCH v2] x86/hyperv: Fix kexec panic/hang issues
Message-ID: <20210105130423.nvxpsdvgn5zier4v@liuwe-devbox-debian-v2>
References: <20201222065541.24312-1-decui@microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201222065541.24312-1-decui@microsoft.com>
User-Agent: NeoMutt/20180716
Precedence: bulk

On Mon, Dec 21, 2020 at 10:55:41PM -0800, Dexuan Cui wrote:
> Currently the kexec kernel can panic or hang due to 2 causes:
> 
> 1) hv_cpu_die() is not called upon kexec, so the hypervisor corrupts the
> old VP Assist Pages when the kexec kernel runs. The same issue is fixed
> for hibernation in commit 421f090c819d ("x86/hyperv: Suspend/resume the
> VP assist page for hibernation"). Now fix it for kexec.
> 
> 2) hyperv_cleanup() is called too early. In the kexec path, the other CPUs
> are stopped in hv_machine_shutdown() -> native_machine_shutdown(), so
> between hv_kexec_handler() and native_machine_shutdown(), the other CPUs
> can still try to access the hypercall page and cause panic. The workaround
> "hv_hypercall_pg = NULL;" in hyperv_cleanup() is unreliabe. Move
> hyperv_cleanup() to a better place.
> 
> Signed-off-by: Dexuan Cui <decui@microsoft.com>

The code looks a bit intrusive. On the other hand, this does sound like
something needs backporting for older stable kernels.

On a more practical note, I need to decide whether to take it via
hyperv-fixes or hyperv-next. What do you think?

Wei.