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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id EA47BC48BC3 for ; Wed, 14 Feb 2024 20:16:47 +0000 (UTC) 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=1MFpF6yNY0E2HZMloowiQIAFlrRI5ldRIorO1XFtdbI=; b=Diwl11bL3jxcE1 J7nx8noruQNAmEtD5g4q6gz//Gv7PTVoeO5S1ieREj7rfId7EdyDfF+IZ8P/EWOT+IWB7ymuX16VP aYTw2budaXGnkL1FEPihNWWodhlFX8RqNWZS9YjEZe4lBaK721vs+8S2WbeOaz+nhuaHgyMe56K6p T3wGnSjMrsLUkASLS5GcqPyG7JD2cxSYLVkwtiSeOEC/erUxLOUc3G07/fF8y+QKVGULr8Ofxku47 oT9yi8bOMP+3+bTTP+s9IT0WBGijbqVbccmsx50nou5purtCHubDqXvcbrQIMbMkmAcamfHk4FiGb o4T5NkgkE8HE3oapHbuQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1raLgD-0000000EAig-22xt; Wed, 14 Feb 2024 20:16:29 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1raLgB-0000000EAiG-1eMQ for linux-arm-kernel@lists.infradead.org; Wed, 14 Feb 2024 20:16:28 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D87D760FD3; Wed, 14 Feb 2024 20:16:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78F37C433F1; Wed, 14 Feb 2024 20:16:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1707941786; bh=m48ScHz01LrC5ODGklW8vI2Tg3kZV3wo3kXFm58JWJw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=VYFjoJX5/XIUVyjrzowPYK1H26pv6+cowKdJ5tPwIUAGpLwwlVKx8ikQnnol+Obvv hyylNjPsdOwfj8b+3r+odjV42Roke+V9O9zp6LN5fIl/IE90hG8GjKFT4kJAiFzTVd dGYW0OXvg2jQPhjgF5XyuNYl1a69JIseb1oABrBk30DBI8usfowLVejTXdtoyX2kgC fbVBGDDb+4LQK/jA8gcPua0+ddVzOEb0xTWeg03XjwMjTw9Qr+8cHSbMkV4RuyWYwE MyHyGCeu212J6CDVcaRkPp6Fw4Ks8fk8Q8xuGY0K/WGB6RUEHxLJODD+edN0yusl75 umt5Rao0p+9rg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1raLg8-003GNh-33; Wed, 14 Feb 2024 20:16:24 +0000 Date: Wed, 14 Feb 2024 20:16:23 +0000 Message-ID: <86ttma4x9k.wl-maz@kernel.org> From: Marc Zyngier To: Eric Auger Cc: Jing Zhang , KVM , KVMARM , ARMLinux , Oliver Upton , Will Deacon , Paolo Bonzini , James Morse , Alexandru Elisei , Suzuki K Poulose , Fuad Tabba , Suraj Jitindar Singh , Cornelia Huck , Shaoqin Huang , Sebastian Ott Subject: Re: [PATCH v1 2/4] KVM: arm64: Document KVM_ARM_GET_REG_WRITABLE_MASKS In-Reply-To: <25434f0e-d9c9-45dc-82a1-7466bc59a6e2@redhat.com> References: <20230919175017.538312-1-jingzhangos@google.com> <20230919175017.538312-3-jingzhangos@google.com> <82b72bd2-c079-40c3-90b8-30174f2a8fe0@redhat.com> <86a5o45sb8.wl-maz@kernel.org> <25434f0e-d9c9-45dc-82a1-7466bc59a6e2@redhat.com> 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/29.1 (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: 185.219.108.64 X-SA-Exim-Rcpt-To: eauger@redhat.com, jingzhangos@google.com, kvm@vger.kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, oliver.upton@linux.dev, will@kernel.org, pbonzini@redhat.com, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, tabba@google.com, surajjs@amazon.com, cohuck@redhat.com, shahuang@redhat.com, sebott@redhat.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-20240214_121627_541518_6BDA2D7E X-CRM114-Status: GOOD ( 26.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 Hi Eric, On Wed, 14 Feb 2024 18:07:58 +0000, Eric Auger wrote: > > > I'm not sure SEIS is such an easy one: if you promised the guest that > > it would never get an SError doing the most stupid things (SEIS=0), it > > really shouldn't get one after migration. If you advertised it on the > > source HW (Altra), a migration to TX2 would be fine. > I see. Indeed for sure we must make sure KVM cannot inject SEIs in the > guest if SEIS is not advertised on guest side. The problem isn't KVM injecting an SError, but the HW doing it (that's what SEIS indicates). On some HW, it only takes an old enough EFI build to trigger those. > In this case SEIS is 0 on src Altra. On dst TX2 ich_vtr_el2 advertises > it and host seis =1 causing set_gic_ctlr to fail (vgic-sys-reg-v3.c). > > > > > The other bits are possible to change depending on the requirements of > > the VM (aff3, IDBits), and ExtRange should always be set to 0 (because > > our GIC implementation doesn't support EPPI/ESPI). > > > > The really ugly part here is that if you want to affect these bits, > > you will need to trap and emulate the access. Not a big deal, but in > > the absence of FGT, you will need to handle the full Common trap > > group, which is going to slow things down (you will have to trap > > ICV_PMR_EL1, for example). > Would it be sensible to simplify things and only support the new range > if FGT is supported? I'm not sure that helps. The only FGT that covers the GIC is for ICC_IGRPENn_EL1, and we don't care much about that guy. So ICH_VMCR_EL2.TC it is, and that sucks a bit. But if that's what you want to show, you don't have a choice. 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