From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Subject: Re: [PATCH v2 02/36] KVM: arm64: Rework hyp_panic for VHE and non-VHE Date: Sat, 09 Dec 2017 17:24:38 +0000 Message-ID: <867etvstk9.wl-marc.zyngier@arm.com> References: <20171207170630.592-1-christoffer.dall@linaro.org> <20171207170630.592-3-christoffer.dall@linaro.org> Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Shih-Wei Li , Andrew Jones To: Christoffer Dall Return-path: Received: from foss.arm.com ([217.140.101.70]:46984 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751038AbdLIRYn (ORCPT ); Sat, 9 Dec 2017 12:24:43 -0500 In-Reply-To: <20171207170630.592-3-christoffer.dall@linaro.org> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, 07 Dec 2017 17:05:56 +0000, Christoffer Dall wrote: > > VHE actually doesn't rely on clearing the VTTBR when returning to the > host kernel, and that is the current key mechanism of hyp_panic to > figure out how to attempt to return to a state good enough to print a > panic statement. > > Therefore, we split the hyp_panic function into two functions, a VHE and > a non-VHE, keeping the non-VHE version intact, but changing the VHE > behavior. > > The vttbr_el2 check on VHE doesn't really make that much sense, because > the only situation where we can get here on VHE is when the hypervisor > assembly code actually called into hyp_panic, which only happens when > VBAR_EL2 has been set to the KVM exception vectors. On VHE, we can > always safely disable the traps and restore the host registers at this > point, so we simply do that unconditionally and call into the panic > function directly. > > Signed-off-by: Christoffer Dall Acked-by: Marc Zyngier M. -- Jazz is not dead, it just smell funny.