From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CA8072DEA60 for ; Tue, 8 Jul 2025 12:47:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751978872; cv=none; b=dsJ7Xc4tj/053FLw8m62U9WFKvKnzZkH26UWCMrALFSfNaE55frnVHVHMP+u/vFjAjAhdaGaULw2OjusBUwUpisGJu5gIuRIdiJqv/6gNkEDlXZwTybKWd+s3Qrhi9vophhDznIryz1C91ax2MUaIRBdOnonGVKFHAKes6rNY00= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751978872; c=relaxed/simple; bh=+wvoob8grI10NwfBtRPmsZFoGIB2FSIYS3UA5QZQBaQ=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=o6XdaTpaB5kQFuMm+mUcGIDrBGDdrbpMWyvFYfoUuFtNFi6/CUlR56y4V+Zc6q980no6TO2BxYPE0Z5kLXoPVs9Xl+ygHa7BMjscIA4x9nBjN+0f27R5flmwrCesqfQ9dY7sNe4H4U9q5ByqslU/MtXLkDnJJKQF3+yTAP7SY1A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IZBKe9yG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IZBKe9yG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A74EAC4CEF6; Tue, 8 Jul 2025 12:47:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751978872; bh=+wvoob8grI10NwfBtRPmsZFoGIB2FSIYS3UA5QZQBaQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=IZBKe9yGbPI51lmlJS++hmFbJmAWwkWsEVz1TBMfewPRDKrYdYYQnQP/miJTWuxOG V+0eYUNYYnSYp+m7DKwrGMFQN4lOigu6iXyVZi9IIS280lcjgKIebp5ab+7Y/sY86D mVM7A2iazCWytAxyFA6iV6reBBh/kYdSQhCeNeMKw69RbEFXqXyvl2TFIK7WkFf7Ad VEN/y9C466iGbFzBk7hK0oDbSBGZr78Xeu9C2e9KJDmxTHGP5TV3f9eSk56XVYnEBn 4uasFO1iB+1PGlDkGK7QFJMdiY7LITb6GxPu+/IZQLRa3ZBNN+E703N3Pw10I6iXwR ZjdBjdb5dfsjA== 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 1uZ7jh-00DkqN-SY; Tue, 08 Jul 2025 13:47:50 +0100 Date: Tue, 08 Jul 2025 13:47:47 +0100 Message-ID: <86sej6alxo.wl-maz@kernel.org> From: Marc Zyngier To: Zhou Wang Cc: Oliver Upton , Will Deacon , Catalin Marinas , , , , Subject: Re: [PATCH] ARM64: errata: Add workaround for HIP10/HIP10C erratum 162200803 In-Reply-To: <73ee91b8-ba15-2534-ab76-f64e59261b1e@hisilicon.com> References: <20250626124142.2035110-1-wangzhou1@hisilicon.com> <86wm8ybpk5.wl-maz@kernel.org> <0b54db94-8a6f-cea0-a6f7-dbe8650d66dd@hisilicon.com> <86h5zwba5i.wl-maz@kernel.org> <864ivtbll0.wl-maz@kernel.org> <73ee91b8-ba15-2534-ab76-f64e59261b1e@hisilicon.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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: wangzhou1@hisilicon.com, oliver.upton@linux.dev, will@kernel.org, catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, tangnianyao@huawei.com, wangwudi@hisilicon.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Tue, 08 Jul 2025 13:05:24 +0100, Zhou Wang wrote: >=20 > On 2025/7/3 18:44, Marc Zyngier wrote: > > On Wed, 02 Jul 2025 10:57:13 +0100, > > Zhou Wang wrote: > >> > >> However=EF=BC=8Cmigration between different KVMs will be broken :( > >> I am not sure that should we consider this case as well? > >=20 > > This isn't optional. You cannot break migration on existing systems, > > and the only case that *must* break is to restore a VM that hasn't > > seen this limitation on a HW that enforces it. >=20 > So the whole story is that we should let GICD_TYPE.num_LPIs as a > writable field, and set this field from VMM(e.g. QEMU). And it will > be failed if doing migration between VMs with different num_LPI > configurations. Note that on a non-broken system, setting num_LPIs to any value should always work. > After above done, this errata could be added. Which would be the only case where num_LPIs wouldn't be writable, and set to a fixed value. Note that an alternative would be to not have a kernel erratum, but to force num_LPIs from userspace when running on your platform. But that implies that: you have your own, non-upstream VMM, and that there is no opportunity for userspace to adversely impact the system as a whole. > Not sure my thought above is right? I will try to prepare a num_LPIs > writable patch if the direction is right. I think you got the gist of it. Thanks, M. --=20 Without deviation from the norm, progress is not possible.