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 538D47260F for ; Tue, 1 Jul 2025 08:14:20 +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=1751357660; cv=none; b=KODiobZaD+DMxroHzRJ+Em8FyB/fcJqyj9evnZsbu1v8k+z2HQU04xn/1gM8EEPYh83lNVhzYCFgG4WCmg9iHLpepSX8RNNJVH7SqOuGqSyYBAvHGp2/uKSKdTzy1ltsujC5KSKsptOtOZ/Lfnps/Yuql+H2Vq0ChTi9UklOUPU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751357660; c=relaxed/simple; bh=+DZ09FEazCWymldSBe2DHALApCtx76xTJrchpStCGs4=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Yrjg9VVRn/bKF+tfv4WNhnLE60a2BsZS4VVzky/9bdEcUtk5VBo+RQMykgFXPOIflD8cXSDVnNv+XzVqz/ve9yF4faFouaghAZgLATVrBUcSUOL8B5YikK4jNAY7OdvYOrqYF6lX8d0DroQP9yPhBeO8XaDqAPvBS2KaZMeO5I8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=u6Xp4cw1; 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="u6Xp4cw1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1495C4CEEB; Tue, 1 Jul 2025 08:14:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751357660; bh=+DZ09FEazCWymldSBe2DHALApCtx76xTJrchpStCGs4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=u6Xp4cw10gOkhmmnjzE8UWPuuS/fQTQXPIq+j62Qq62Zo+b8/pevLL6tb1WXuNY/m N4mhSXTVWkX7HFo7Ra7hGJkceZjMT7RvOnxlhC91B6ptepQVc1yNRS3FCiPZqsLG0+ TsKCZtD60NppRHrVRCBOqsa/gGeH8bIRsddwx9C8pWtDZv9uyl2NgL0yzaE/bIvsGf Dm0uomLmogYcLhmuuRV61DwWcRu5RHNfg558JsOtQzoTyTyE2+U7Ef4U/3K6kPyYYq pwKOkAlfAn6wjhJSNp2CXmo3dIvc1RjIUqBSbtwAacTYRxjtkGxSe9rfRo98Ars7EC if32qJMNcsnSQ== 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 1uWW89-00BTdC-Id; Tue, 01 Jul 2025 09:14:17 +0100 Date: Tue, 01 Jul 2025 09:14:17 +0100 Message-ID: <86h5zwba5i.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: <0b54db94-8a6f-cea0-a6f7-dbe8650d66dd@hisilicon.com> References: <20250626124142.2035110-1-wangzhou1@hisilicon.com> <86wm8ybpk5.wl-maz@kernel.org> <0b54db94-8a6f-cea0-a6f7-dbe8650d66dd@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=US-ASCII 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 Fri, 27 Jun 2025 07:36:31 +0100, Zhou Wang wrote: > > On 2025/6/26 21:27, Marc Zyngier wrote: > > On Thu, 26 Jun 2025 13:41:42 +0100, > > Zhou Wang wrote: > >> > >> For GICv4.0 of Hip10 and Hip10C, it has a SoC bug with vPE schedule: > >> when multiple vPEs are sending vpe schedule/deschedule commands > >> concurrently and repeatedly, some vPE schedule command may not be > >> scheduled, and it will cause the command timeout. > >> > >> The hardware implementation is that there is one GIC hardware in one CPU die, > >> which handles all vPE schedule operations one by one in all CPUs of this die. > >> The bug is that if the number of queued vPE schedule operations is more > >> than a certain value, the last vPE schedule operation will be lost. > >> > >> One possible way to solve this problem is to limit the number of vLPIs, so > >> the hardware could spend less time to scan virtual pending table when it > >> handles the vPE schedule operations, so the queued vPE schedule operations > >> will never be more than above certain value. > >> > >> Given the number of CPUs of die, and imagine there is 100 vPE schedule > >> operations per second one CPU, it can be calculated that we can limit > >> the number of vLPI to 4096 for virtual machine to avoid the issue. > >> > >> Signed-off-by: Zhou Wang > >> --- > >> Documentation/arch/arm64/silicon-errata.rst | 2 ++ > >> arch/arm64/Kconfig | 12 ++++++++++++ > >> arch/arm64/include/asm/cputype.h | 4 ++++ > >> arch/arm64/kernel/cpu_errata.c | 15 +++++++++++++++ > >> arch/arm64/kvm/vgic/vgic-mmio-v3.c | 5 +++++ > >> arch/arm64/tools/cpucaps | 1 + > >> include/linux/irqchip/arm-gic-v3.h | 1 + > >> 7 files changed, 40 insertions(+) > >> > > > > [...] > > > >> diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c > >> index ae4c0593d114..495a56e9dc4b 100644 > >> --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c > >> +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c > >> @@ -81,6 +81,11 @@ static unsigned long vgic_mmio_read_v3_misc(struct kvm_vcpu *vcpu, > >> if (vgic_has_its(vcpu->kvm)) { > >> value |= (INTERRUPT_ID_BITS_ITS - 1) << 19; > >> value |= GICD_TYPER_LPIS; > >> + /* Limit the number of vlpis to 4096 */ > >> + if (cpus_have_final_cap(ARM64_WORKAROUND_HISI_162200803) && > >> + kvm_vgic_global_state.has_gicv4 && > >> + !kvm_vgic_global_state.has_gicv4_1) > >> + value |= 11 << GICD_TYPER_NUM_LPIS_SHIFT; > > > > This really doesn't solve your problem. Yes, the guest *may* honor > > this limit. But KVM doesn't care and will happily allocate 2^16 vLPIs > > if the guest asks -- there is no code enforcing this limit. > > Hi Marc, > > I am not sure if there is any other place guest can ask vLPI over > the limitation except for MAPTI/MAPT below? > > > And even if we did. What would we do on a MAPTI command that tries to > > map a vLPI outside of the allowed range? Do we need to tell the guest > > it has screwed up? > > Thanks for pointing this. Yes, we miss the lpi_nr checking in vgic_its_cmd_handle_mapi. > In fact, the fix of this errata introduces the usage of GICD.num_LPI, > so we need make related logic right as well. Exactly. > > I am not sure that if we could add related checking for lpi_nr in MAPTI/MAPI > as part of this errata fix, or we should add the basic support for > GICD.num_LPI before adding this errata? You definitely need to handle that before allowing such limit to be enforced. Which also means allowing the limit to be saved/restored from userspace in order to support migration. I was really hoping to never have to support this thing (it really is terrible), but if we have to introduce and honor it for correctness reasons, then it has to be fully supported. Thanks, M. -- Without deviation from the norm, progress is not possible.