From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792597056; b=XSl6/IAEgFXbBGLSpiciH+r1Yps92unSOZ64Y0wS275aBI80AT/R00PGNlhdPhIgCVWv ikM4jFF2wYieh4hAxHtxI+JnYmvXom+2GVJkG+o93B58kabqWgr86q1qPBvlHJIK8uTFF Ct7rVuQew1JdlkESyhsflk4YKXonfnpmEtSoazGSSR6fzhnDyvsJHIT0nd5++lXkxJ7rq AntqaW679xlJkFVrM34UMN+WkHFSUa6h2b9dHsmRCI3kHB6uOOFmgLxevrwW5HF7nTE/O 30mVTaW+SgWGK14mz6cFoTsAl33SJTGXtWR9dCRcjVqNhYPTJUGfbeDBKkHu+mpMMgw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792597056; h=Received:DKIM-Signature:Received:Date:Message-ID:From:To:Cc:Subject: In-Reply-To:References:User-Agent:MIME-Version:Content-Type: X-SA-Exim-Connect-IP:X-SA-Exim-Rcpt-To:X-SA-Exim-Mail-From: X-SA-Exim-Scanned; bh=151osnyqTqNRy9yGvwwtrRpNABKKk4npuM+xHhPMEdc=; b=b8dzw9jtgIxCED1TaP22ihIm4G5T0CvStACCPOBrfouFV/OCnOm8ruCOvYS6s7aE+S85 wAPnivdyhUzExug80lcTCyQRRHTXX7EmmI5vnzEPTeVaTbwdzHhvsrZZ7x8qEZg3WIuYh /4qUUKF51gEWn2pksvZV8xxp5HcDj5xybeaQYTKHzBPD72nC84kI652KvHerVGUnJUnEG 8QqeEot2YIPo94rif0vGDoMn3cQ0QcorrfhNRra6ACjV1qx6Jbga39g12Sv28ViGnTX92 oXRmLg0Xb71UrFUajIrdUd0WnpHtrd0W5rVX44AXPow0JQYYvm1WECcdJdOhrprfpWg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=LZlUa8sk; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B1382606A319; Wed, 21 Oct 2026 15:37:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=LZlUa8sk Received: by smtp.kernel.org (Postfix) with ESMTPSA id 490D41F000C1; Wed, 21 Oct 2026 15:37:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792597055; bh=151osnyqTqNRy9yGvwwtrRpNABKKk4npuM+xHhPMEdc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=LZlUa8skphlwi4uXJ9gjrUnssf7gpReG91Bk/DKT+IMLa5CjHH4Sen2zDoYK7qxdi CGXBT+8RggG/CIIyN7YEHpJWjZiwZvmeAuvi0zv3QU8n+XAG2QjZEa0an89uKrEDNU Zh6vtp3lAx2xhPIwDGcYy/QNHWf0OVPAQft7yr9HtV/R5aYIhbHhTF7d3eeVV6+bSM oIFVo1tRZ+jQHFE6BVFfJvs1teBdUPEir8wBOnfjF0ffX0XX5tRgn/zai/656vWnun DVh7q6ismi/NsXhv0cJBFcPSt3VP2xqqMI2kns1H3uN6evQ35LB9/02YLHvf49f9JH 69HXyicRfywFw== 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.98.2) (envelope-from ) id 1xJYNh-00000005jCk-1CgX; Wed, 21 Oct 2026 15:37:33 +0000 Date: Wed, 21 Oct 2026 16:37:32 +0100 Message-ID: <86jynbyshv.wl-maz@kernel.org> From: Marc Zyngier To: Vincent Donnefort Cc: oupton@kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, kernel-team@android.com, fuad.tabba@linux.dev, stable@vger.kernel.org Subject: Re: [PATCH v1] KVM: arm64: pkvm: Clear GICv3 LRs in the hypervisor In-Reply-To: References: <20261021110000.508827-1-vdonnefort@google.com> <86qzhjz1iz.wl-maz@kernel.org> <86pkx3yylb.wl-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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list 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: vdonnefort@google.com, oupton@kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, kernel-team@android.com, fuad.tabba@linux.dev, stable@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 21 Oct 2026 16:14:21 +0100, Vincent Donnefort wrote: > > On Wed, Oct 21, 2026 at 02:25:52PM +0100, Marc Zyngier wrote: > > On Wed, 21 Oct 2026 13:50:22 +0100, > > Vincent Donnefort wrote: > > > > > > On Wed, Oct 21, 2026 at 01:22:28PM +0100, Marc Zyngier wrote: > > > > On Wed, 21 Oct 2026 12:00:00 +0100, > > > > Vincent Donnefort wrote: > > > > > > > > > > The LR registers are architecturally UNKNOWN when the CPU boots or > > > > > resumes. However, in protected mode, only the used ones are reset. > > > > > During boot the HVC __vgic_v3_init_lrs() is never called because > > > > > vgic_present is only set in init_subsystems(), after cpu_hyp_init() was > > > > > called. > > > > > > > > Why don't you fix this rather than making the init even more > > > > different? > > > > > > Ack, I'll make a patch to fix that first. > > > > > > > > > > > > Also, the PM notifier isn't registered for pKVM and the HVC > > > > > becomes unavailable after the host is deprivileged. > > > > > > > > Sanitising the LRs on PSCI_ON is probably the right thing to do, but I > > > > don't understand why resetting the LRs is out of reach from the host, > > > > given that the host is fully in charge of the interrupt injection, and > > > > therefore controls the LRs. > > > > > > I suppose I could reinstantiate the pm callbacks for pkvm to at least reset the > > > LRs? > > > > I think there are two different things: > > > > - pKVM must not rely on the host resetting the LRs once it is > > deprivileged (that's the PSCI_ON case) > > Definitely not a hot path, but if we keep this one ^, isn't a shame of making > the host issue HVCs on CPU resume to reset the LRs if we know the hypervisor did > it anyway? The really annoying thing is that we have divergence between hypervisor backends that make the code fragile and harder to maintain. Specially as we add CCA to the mix. So my approach to this is to stop messing with the host code. It should do what it is notionally supposed to do, and the hypervisor code can do its own stuff. You can always optimise away the reset on PSCI_ON if you add some tracking. Is it worth it? Absolutely not. But that's where the complexity should go. Thanks, M. -- Without deviation from the norm, progress is not possible.