From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Subject: Re: [PATCH v6 06/10] arm64: hyperv: Add kexec and panic handlers Date: Sun, 15 Mar 2020 18:15:44 +0000 Message-ID: <86tv2pzdpr.wl-maz@kernel.org> References: <1584200119-18594-1-git-send-email-mikelley@microsoft.com> <1584200119-18594-7-git-send-email-mikelley@microsoft.com> Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Return-path: Received: from mail.kernel.org ([198.145.29.99]:51154 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729030AbgCOSPt (ORCPT ); Sun, 15 Mar 2020 14:15:49 -0400 In-Reply-To: <1584200119-18594-7-git-send-email-mikelley@microsoft.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Michael Kelley Cc: will@kernel.org, ardb@kernel.org, arnd@arndb.de, catalin.marinas@arm.com, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-efi@vger.kernel.org, linux-arch@vger.kernel.org, olaf@aepfle.de, apw@canonical.com, vkuznets@redhat.com, jasowang@redhat.com, marcelo.cerri@canonical.com, kys@microsoft.com, sunilmut@microsoft.com, boqun.feng@gmail.com On Sat, 14 Mar 2020 15:35:15 +0000, Michael Kelley wrote: > > Add functions to set up and remove kexec and panic > handlers, and to inform Hyper-V about a guest panic. > These functions are called from architecture independent > code in the VMbus driver. > > This code is built only when CONFIG_HYPERV is enabled. > > Signed-off-by: Michael Kelley > --- > arch/arm64/hyperv/hv_core.c | 61 ++++++++++++++++++++++++++++++++++++++++++++ > arch/arm64/hyperv/mshyperv.c | 26 +++++++++++++++++++ > 2 files changed, 87 insertions(+) > > diff --git a/arch/arm64/hyperv/hv_core.c b/arch/arm64/hyperv/hv_core.c > index 4aa6b8f..8d6de9f 100644 > --- a/arch/arm64/hyperv/hv_core.c > +++ b/arch/arm64/hyperv/hv_core.c > @@ -199,3 +199,64 @@ void hv_get_vpreg_128(u32 msr, struct hv_get_vp_register_output *res) > kfree(output); > } > EXPORT_SYMBOL_GPL(hv_get_vpreg_128); > + > +void hyperv_report_panic(struct pt_regs *regs, long err) > +{ > + static bool panic_reported; > + u64 guest_id; > + > + /* > + * We prefer to report panic on 'die' chain as we have proper > + * registers to report, but if we miss it (e.g. on BUG()) we need > + * to report it on 'panic'. > + */ > + if (panic_reported) > + return; > + panic_reported = true; How does this work when multiple vcpus are crashing at once? Are you guaranteed to be single-threaded at this point? > + > + guest_id = hv_get_vpreg(HV_REGISTER_GUEST_OSID); > + > + /* > + * Hyper-V provides the ability to store only 5 values. > + * Pick the passed in error value, the guest_id, and the PC. > + * The first two general registers are added arbitrarily. > + */ > + hv_set_vpreg(HV_REGISTER_CRASH_P0, err); > + hv_set_vpreg(HV_REGISTER_CRASH_P1, guest_id); > + hv_set_vpreg(HV_REGISTER_CRASH_P2, regs->pc); > + hv_set_vpreg(HV_REGISTER_CRASH_P3, regs->regs[0]); > + hv_set_vpreg(HV_REGISTER_CRASH_P4, regs->regs[1]); How about reporting useful information, a pointer to some data structure describing the fault? As it is, the usefulness of this is pretty dubious. > + > + /* > + * Let Hyper-V know there is crash data available > + */ > + hv_set_vpreg(HV_REGISTER_CRASH_CTL, HV_CRASH_CTL_CRASH_NOTIFY); > +} > +EXPORT_SYMBOL_GPL(hyperv_report_panic); > + > +/* > + * hyperv_report_panic_msg - report panic message to Hyper-V > + * @pa: physical address of the panic page containing the message > + * @size: size of the message in the page > + */ > +void hyperv_report_panic_msg(phys_addr_t pa, size_t size) > +{ > + /* > + * P3 to contain the physical address of the panic page & P4 to > + * contain the size of the panic data in that page. Rest of the > + * registers are no-op when the NOTIFY_MSG flag is set. > + */ > + hv_set_vpreg(HV_REGISTER_CRASH_P0, 0); > + hv_set_vpreg(HV_REGISTER_CRASH_P1, 0); > + hv_set_vpreg(HV_REGISTER_CRASH_P2, 0); > + hv_set_vpreg(HV_REGISTER_CRASH_P3, pa); > + hv_set_vpreg(HV_REGISTER_CRASH_P4, size); > + > + /* > + * Let Hyper-V know there is crash data available along with > + * the panic message. > + */ > + hv_set_vpreg(HV_REGISTER_CRASH_CTL, > + (HV_CRASH_CTL_CRASH_NOTIFY | HV_CRASH_CTL_CRASH_NOTIFY_MSG)); > +} > +EXPORT_SYMBOL_GPL(hyperv_report_panic_msg); > diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c > index ae6ece6..c58940d 100644 > --- a/arch/arm64/hyperv/mshyperv.c > +++ b/arch/arm64/hyperv/mshyperv.c > @@ -23,6 +23,8 @@ > > static void (*vmbus_handler)(void); > static void (*hv_stimer0_handler)(void); > +static void (*hv_kexec_handler)(void); > +static void (*hv_crash_handler)(struct pt_regs *regs); Why is this in the arch-specific code? Yes, it lives in the x86 arch code too, but I don't see what prevents it from being moved to the vmbus_drv.c code. > > static int vmbus_irq; > static long __percpu *vmbus_evt; > @@ -137,3 +139,27 @@ void hv_remove_stimer0_irq(int irq) > } > } > EXPORT_SYMBOL_GPL(hv_remove_stimer0_irq); > + > +void hv_setup_kexec_handler(void (*handler)(void)) > +{ > + hv_kexec_handler = handler; > +} > +EXPORT_SYMBOL_GPL(hv_setup_kexec_handler); > + > +void hv_remove_kexec_handler(void) > +{ > + hv_kexec_handler = NULL; > +} > +EXPORT_SYMBOL_GPL(hv_remove_kexec_handler); > + > +void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs)) > +{ > + hv_crash_handler = handler; > +} > +EXPORT_SYMBOL_GPL(hv_setup_crash_handler); > + > +void hv_remove_crash_handler(void) > +{ > + hv_crash_handler = NULL; > +} > +EXPORT_SYMBOL_GPL(hv_remove_crash_handler); > -- > 1.8.3.1 > > Thanks, M. -- Jazz is not dead, it just smells funny. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18498C18E5B for ; Sun, 15 Mar 2020 18:15:56 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E111F206B1 for ; Sun, 15 Mar 2020 18:15:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="CHw5dd24"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="eR5MFeqr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E111F206B1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0NkUToIbhD2CW9H367usS7M6b6eb6omxJbNgZROlQYM=; b=CHw5dd249mpY4P rrZ9XK+tjJpFq0s8jT98lNe7oBxtNO86w9Ie3DFmgp+XEr/nQbLHpQUS8XFyrhEk6YE5ftFu5gZvP o/0D6PDH6KoOWicTuxQieueiXCoDDQbtsvHllT08+4CAFZYBXtTte5oLMNX57hQ4HnFo+Rx58Z39D SH9JitsSzkBQNml7p2U+LwSNtlUxiLiA1mjf4f8p0d2YWbRZq6k+iZKBzsq29MvKiEWUTjHXUZ5rp 5sen3XQ+IMfD8Dru109i+Pb4bIFzAvQyH63vz6VPCS2eGb22A8KKtvPMyRM32D9PxbehBxZVOdAY0 zdoOgc7S2cALsE7yJ7nQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jDXnk-0006yZ-Dx; Sun, 15 Mar 2020 18:15:52 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jDXnh-0006y5-7O for linux-arm-kernel@lists.infradead.org; Sun, 15 Mar 2020 18:15:50 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A9082206B1; Sun, 15 Mar 2020 18:15:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584296148; bh=q/mdVrbaFEPnsHVdyTsaw/hsSwbkVrdYfQPhvan8LrM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=eR5MFeqreycD2VC3I2bu6e/DElwBPgtuFyuRX5oRaxyoSW0rII7pfatrziBOdbzNi 6wfwaPM9Uw+IZQ9Vce8GnMClENqodPAEPH4brijlD+3v+c87owNiVxSLb7lcBm53SD wURiXqizBWXsw05Hy3tY8FRBuCqzDC1g4zsrOKaA= Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=big-swifty.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jDXne-00Cv06-UB; Sun, 15 Mar 2020 18:15:47 +0000 Date: Sun, 15 Mar 2020 18:15:44 +0000 Message-ID: <86tv2pzdpr.wl-maz@kernel.org> From: Marc Zyngier To: Michael Kelley Subject: Re: [PATCH v6 06/10] arm64: hyperv: Add kexec and panic handlers In-Reply-To: <1584200119-18594-7-git-send-email-mikelley@microsoft.com> References: <1584200119-18594-1-git-send-email-mikelley@microsoft.com> <1584200119-18594-7-git-send-email-mikelley@microsoft.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: mikelley@microsoft.com, will@kernel.org, ardb@kernel.org, arnd@arndb.de, catalin.marinas@arm.com, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-efi@vger.kernel.org, linux-arch@vger.kernel.org, olaf@aepfle.de, apw@canonical.com, vkuznets@redhat.com, jasowang@redhat.com, marcelo.cerri@canonical.com, kys@microsoft.com, sunilmut@microsoft.com, boqun.feng@gmail.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200315_111549_307826_920F85F9 X-CRM114-Status: GOOD ( 26.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, linux-arch@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-efi@vger.kernel.org, boqun.feng@gmail.com, arnd@arndb.de, catalin.marinas@arm.com, jasowang@redhat.com, sunilmut@microsoft.com, linux-kernel@vger.kernel.org, marcelo.cerri@canonical.com, olaf@aepfle.de, gregkh@linuxfoundation.org, apw@canonical.com, vkuznets@redhat.com, kys@microsoft.com, will@kernel.org, ardb@kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, 14 Mar 2020 15:35:15 +0000, Michael Kelley wrote: > > Add functions to set up and remove kexec and panic > handlers, and to inform Hyper-V about a guest panic. > These functions are called from architecture independent > code in the VMbus driver. > > This code is built only when CONFIG_HYPERV is enabled. > > Signed-off-by: Michael Kelley > --- > arch/arm64/hyperv/hv_core.c | 61 ++++++++++++++++++++++++++++++++++++++++++++ > arch/arm64/hyperv/mshyperv.c | 26 +++++++++++++++++++ > 2 files changed, 87 insertions(+) > > diff --git a/arch/arm64/hyperv/hv_core.c b/arch/arm64/hyperv/hv_core.c > index 4aa6b8f..8d6de9f 100644 > --- a/arch/arm64/hyperv/hv_core.c > +++ b/arch/arm64/hyperv/hv_core.c > @@ -199,3 +199,64 @@ void hv_get_vpreg_128(u32 msr, struct hv_get_vp_register_output *res) > kfree(output); > } > EXPORT_SYMBOL_GPL(hv_get_vpreg_128); > + > +void hyperv_report_panic(struct pt_regs *regs, long err) > +{ > + static bool panic_reported; > + u64 guest_id; > + > + /* > + * We prefer to report panic on 'die' chain as we have proper > + * registers to report, but if we miss it (e.g. on BUG()) we need > + * to report it on 'panic'. > + */ > + if (panic_reported) > + return; > + panic_reported = true; How does this work when multiple vcpus are crashing at once? Are you guaranteed to be single-threaded at this point? > + > + guest_id = hv_get_vpreg(HV_REGISTER_GUEST_OSID); > + > + /* > + * Hyper-V provides the ability to store only 5 values. > + * Pick the passed in error value, the guest_id, and the PC. > + * The first two general registers are added arbitrarily. > + */ > + hv_set_vpreg(HV_REGISTER_CRASH_P0, err); > + hv_set_vpreg(HV_REGISTER_CRASH_P1, guest_id); > + hv_set_vpreg(HV_REGISTER_CRASH_P2, regs->pc); > + hv_set_vpreg(HV_REGISTER_CRASH_P3, regs->regs[0]); > + hv_set_vpreg(HV_REGISTER_CRASH_P4, regs->regs[1]); How about reporting useful information, a pointer to some data structure describing the fault? As it is, the usefulness of this is pretty dubious. > + > + /* > + * Let Hyper-V know there is crash data available > + */ > + hv_set_vpreg(HV_REGISTER_CRASH_CTL, HV_CRASH_CTL_CRASH_NOTIFY); > +} > +EXPORT_SYMBOL_GPL(hyperv_report_panic); > + > +/* > + * hyperv_report_panic_msg - report panic message to Hyper-V > + * @pa: physical address of the panic page containing the message > + * @size: size of the message in the page > + */ > +void hyperv_report_panic_msg(phys_addr_t pa, size_t size) > +{ > + /* > + * P3 to contain the physical address of the panic page & P4 to > + * contain the size of the panic data in that page. Rest of the > + * registers are no-op when the NOTIFY_MSG flag is set. > + */ > + hv_set_vpreg(HV_REGISTER_CRASH_P0, 0); > + hv_set_vpreg(HV_REGISTER_CRASH_P1, 0); > + hv_set_vpreg(HV_REGISTER_CRASH_P2, 0); > + hv_set_vpreg(HV_REGISTER_CRASH_P3, pa); > + hv_set_vpreg(HV_REGISTER_CRASH_P4, size); > + > + /* > + * Let Hyper-V know there is crash data available along with > + * the panic message. > + */ > + hv_set_vpreg(HV_REGISTER_CRASH_CTL, > + (HV_CRASH_CTL_CRASH_NOTIFY | HV_CRASH_CTL_CRASH_NOTIFY_MSG)); > +} > +EXPORT_SYMBOL_GPL(hyperv_report_panic_msg); > diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c > index ae6ece6..c58940d 100644 > --- a/arch/arm64/hyperv/mshyperv.c > +++ b/arch/arm64/hyperv/mshyperv.c > @@ -23,6 +23,8 @@ > > static void (*vmbus_handler)(void); > static void (*hv_stimer0_handler)(void); > +static void (*hv_kexec_handler)(void); > +static void (*hv_crash_handler)(struct pt_regs *regs); Why is this in the arch-specific code? Yes, it lives in the x86 arch code too, but I don't see what prevents it from being moved to the vmbus_drv.c code. > > static int vmbus_irq; > static long __percpu *vmbus_evt; > @@ -137,3 +139,27 @@ void hv_remove_stimer0_irq(int irq) > } > } > EXPORT_SYMBOL_GPL(hv_remove_stimer0_irq); > + > +void hv_setup_kexec_handler(void (*handler)(void)) > +{ > + hv_kexec_handler = handler; > +} > +EXPORT_SYMBOL_GPL(hv_setup_kexec_handler); > + > +void hv_remove_kexec_handler(void) > +{ > + hv_kexec_handler = NULL; > +} > +EXPORT_SYMBOL_GPL(hv_remove_kexec_handler); > + > +void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs)) > +{ > + hv_crash_handler = handler; > +} > +EXPORT_SYMBOL_GPL(hv_setup_crash_handler); > + > +void hv_remove_crash_handler(void) > +{ > + hv_crash_handler = NULL; > +} > +EXPORT_SYMBOL_GPL(hv_remove_crash_handler); > -- > 1.8.3.1 > > Thanks, M. -- Jazz is not dead, it just smells funny. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel