Received-SPF: pass (google.com: domain of linux-kernel+bounces-2777-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Sun, 17 Dec 2023 18:52:55 +0000
Message-ID: <878r5s8xvc.wl-maz@kernel.org>
From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: Kunkun Jiang <jiangkunkun@huawei.com>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	"moderated list:ARM SMMU DRIVERS" <linux-arm-kernel@lists.infradead.org>,
	kvmarm@lists.linux.dev,
	open list <linux-kernel@vger.kernel.org>,
	"wanghaibin.wang@huawei.com" <wanghaibin.wang@huawei.com>
Subject: Re: [bug report] GICv4.1: vSGI remains pending across the guest reset
In-Reply-To: <ZX8xLhFFqTXRFQtd@linux.dev>
References: <7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com>
	<87a5q983zc.wl-maz@kernel.org>
	<ZX8w1vfQzeXP5klL@linux.dev>
	<ZX8xLhFFqTXRFQtd@linux.dev>
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/28.2
 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
Precedence: bulk
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII

On Sun, 17 Dec 2023 17:34:38 +0000,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> On Sun, Dec 17, 2023 at 05:33:16PM +0000, Oliver Upton wrote:
> > On Sun, Dec 17, 2023 at 11:26:15AM +0000, Marc Zyngier wrote:
> > 
> > [...]
> > 
> > > But this has *nothing* to do with the guest. This is the *host*
> > > userspace performing a write to the redistributor view, which has
> > > different semantics. Which is why your earlier description made no
> > > sense to me.
> > > 
> > > I think the problem is slightly larger than what you describe. A write
> > > to ISPENDR0 should be propagated to the ITS for any values of the
> > > latch, just like this happens on enabling HW-backed SGIs.
> > > 
> > > Can you please give this a go?
> > 
> > What do you think about using this as an opportunity for a bit of
> > cleanup? It'd be nice unify the various MMIO and uaccess handlers for
> > SPENDING + CPENDING while being careful about the arch_timer interrupt.

What is special about the timer interrupt?

> Cut myself off... Meant to say that user writes to SPENDING for GICv3
> can then be treated as:
> 
> > 	clear = ~val;
> > 	vgic_uaccess_write_spending(val);
> > 	vgic_uaccess_write_cpending(clear);

Could be. But I'd rather have separate fixes from more invasive
reworks.  Specially given that we have had multiple ugly bugs around
this code in the past, which is why we ended up splitting userspace
from guest accessors.

	M.

-- 
Without deviation from the norm, progress is not possible.