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.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 311F9C2B9F4 for ; Tue, 22 Jun 2021 16:21:23 +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 006F4610C7 for ; Tue, 22 Jun 2021 16:21:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 006F4610C7 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+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.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc: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=AJtC6mkH5fqJ8BgM/s7D+RaAAomFvQdIiiAdlUNtGWk=; b=WORo4sOcYP40UN fKGnhEGzvs5UTK5/XSnW/lK2t6ZHZAkvDV6ZTac42wNYJLA0ltcNjXdswFdcmvgE/MMhCiM1zVKV8 cAehjP4NTt4sA8eWsPEgEeVVB5hHiodnvJl2TpYgUBbeQ1pVjR6TXUI08ofHWNHGn5oHsrTLlgYl6 iRYVVnOvS6BdvDxhxkl5tb8aF2eZfZ9tPwdfemJbSweKicJJETdSbb+XYa90x0re33mrpqUQXfXOT CXOWqJUNTOgkZkbfWH4cPifl9YbBO296ic+vdcX1q649atfxM2ZWVNB9ayzeM+7ZDJx+T66ctZE9r tRfFgQFJpYYQbhCTusag==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lvj7T-007sWw-4k; Tue, 22 Jun 2021 16:19:23 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lvj7O-007sVy-RZ for linux-arm-kernel@lists.infradead.org; Tue, 22 Jun 2021 16:19:20 +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 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 Cc: linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, James Morse , Suzuki K Poulose , Eric Auger , Hector Martin , Mark Rutland , Zenghui Yu , kernel-team@android.com 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210622_091918_967975_0E385B1E X-CRM114-Status: GOOD ( 38.96 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel