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=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,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 80EBDC2B9F4 for ; Tue, 22 Jun 2021 16:19:23 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id DBE6261289 for ; Tue, 22 Jun 2021 16:19:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DBE6261289 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 737554A003; Tue, 22 Jun 2021 12:19:22 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-Au0p-uAsWb; Tue, 22 Jun 2021 12:19:21 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 3818A407D1; Tue, 22 Jun 2021 12:19:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 9AD334086F for ; Tue, 22 Jun 2021 12:19:20 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yn5OVaMBm6l4 for ; Tue, 22 Jun 2021 12:19:19 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 6C0DC4064F for ; Tue, 22 Jun 2021 12:19:19 -0400 (EDT) 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 6EC7E60FEE; Tue, 22 Jun 2021 16:19:18 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lvj7M-009DG1-BW; Tue, 22 Jun 2021 17:19:16 +0100 Date: Tue, 22 Jun 2021 17:19:15 +0100 Message-ID: <87wnqlc1oc.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei Subject: Re: [PATCH v4 4/9] KVM: arm64: vgic: Let an interrupt controller advertise lack of HW deactivation In-Reply-To: References: <20210601104005.81332-1-maz@kernel.org> <20210601104005.81332-5-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: alexandru.elisei@arm.com, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, suzuki.poulose@arm.com, eric.auger@redhat.com, marcan@marcan.st, mark.rutland@arm.com, yuzenghui@huawei.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: kvm@vger.kernel.org, Hector Martin , kernel-team@android.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Tue, 15 Jun 2021 15:26:02 +0100, Alexandru Elisei wrote: > > Hi Marc, > > On 6/1/21 11:40 AM, Marc Zyngier wrote: > > The vGIC, as architected by ARM, allows a virtual interrupt to > > trigger the deactivation of a physical interrupt. This allows > > the following interrupt to be delivered without requiring an exit. > > > > However, some implementations have choosen not to implement this, > > meaning that we will need some unsavoury workarounds to deal with this. > > > > On detecting such a case, taint the kernel and spit a nastygram. > > We'll deal with this in later patches. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/vgic/vgic-init.c | 10 ++++++++++ > > include/kvm/arm_vgic.h | 3 +++ > > include/linux/irqchip/arm-vgic-info.h | 2 ++ > > 3 files changed, 15 insertions(+) > > > > diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c > > index 6752d084934d..340c51d87677 100644 > > --- a/arch/arm64/kvm/vgic/vgic-init.c > > +++ b/arch/arm64/kvm/vgic/vgic-init.c > > @@ -532,6 +532,16 @@ int kvm_vgic_hyp_init(void) > > return -ENXIO; > > } > > > > + /* > > + * If we get one of these oddball non-GICs, taint the kernel, > > + * as we have no idea of how they *really* behave. > > + */ > > + if (gic_kvm_info->no_hw_deactivation) { > > + kvm_info("Non-architectural vgic, tainting kernel\n"); > > + add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK); > > I'm trying to figure out what are the effects of tainting the > kernel, besides those nasty messages. In > Documentation/admin-guide/tainted-kernels.rst, I found this bit: > > [..] the information is mainly of interest once someone wants to > investigate some problem, as its real cause might be the event that > got the kernel tainted. That's why bug reports from tainted kernels > will often be ignored by developers, hence try to reproduce problems > with an untainted kernel. > > The lack of HW deactivation affects only KVM, I was wondering if we > could taint the kernel the first time a VM created. If the above doc > is to go by, someone who is running Linux on an M1, but not using > KVM, might stand a better chance to get support when something goes > wrong in that case. Unfortunately, by the time we're here, we have already committed to using stuff that isn't architectural. For example, this CPU doesn't advertise a virtual GICv3 CPU interface (because it isn't possible to do so independently of the full-fat one). And right from the beginning, before any VM is present, we are going to access ICH_VTR_EL2, because we really need it as part of initialising KVM. > What do you think? I think that if people are bothered by this tainting, they can disable KVM altogether. And to be fair, we should taint the kernel right when the first CPU boots, because it isn't implementing the ARM architecture as defined by the spec. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm