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 3BD57C35274 for ; Mon, 18 Dec 2023 17:30:31 +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=MCuUtwiLNdbopmSDF7PYlw4xIk8Jn2KenqBmUtDe4CE=; b=iS8cWwD2FV2fXg lCyvPZbs7EVb1b6tJC0HJonmfc9b6Aq8k+DnBrF4ksw6fgHjnPhiet9BM0Z04M+mRfXIso0Cu/t6h zyIe8aSokhpyiAEdxnjQQnLoimTtS28pIAWykxl7HvwqcCOyOOLwHPiC0mtiqX7JDu+qvXbY+Y/B9 bg8Gp7G/Bq5e+T+0NT/2cf4mYUjb0Q2R8DJDpWfhG3LYFJ4VrkEtRSzoVhZxNiO6YG63gxAed4GL1 o5Lhy3Wqs1Yev1Iz2fFZJqKvwjmvasr3c+R2t3Ezc6Z2ZAvlhlh70QSlt/fp64vSqbcqDhke2mWFA pSKKehBbC/R+szRK3xMg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rFHRE-00BdyU-1O; Mon, 18 Dec 2023 17:29:56 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rFHRB-00Bdwg-0N for linux-arm-kernel@lists.infradead.org; Mon, 18 Dec 2023 17:29:54 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 887DCB8101D; Mon, 18 Dec 2023 17:29:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1A76C433C8; Mon, 18 Dec 2023 17:29:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702920590; bh=C5WyAAOndAR8UwN5Lk4RjxcNZZKDcXr2Gv0zWrp9jvE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=g5n4paOl/XTn4kF5V1GTVnAgJTrvITqdFgotD68Fm4l6anGCltOd0lBnx+XhjjYKa ITbM+JjZK5/lnZQCvImsmVekn+Y/qCWgMWMHRDDktmlPdsceqpz5xK7dE94BzkkDOI 0jSYwhj0oddXFyuYiA5nCYBh3XfDvJCmq1Br9WKnAOiqIfFQ/AZNDPUrnXak8j+LZ9 q/I1+I8PdsJQbDRuKVMyN4hktLLJd51eYsNEhBdHxPw/yDOR2lsrXX5qlro/bdO8cB wsEb1bypi83T/GFgocb5LF6KPRzNId11e5F0EU9A6RrI48cexAmFRsOUv6hipusqbz Lg9NqeFuLSIOQ== 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 1rFHR6-0058CE-LU; Mon, 18 Dec 2023 17:29:48 +0000 Date: Mon, 18 Dec 2023 17:29:48 +0000 Message-ID: <86r0jja06r.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: Kunkun Jiang , James Morse , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Jean-Philippe Brucker , "moderated list:ARM SMMU DRIVERS" , kvmarm@lists.linux.dev, open list , "wanghaibin.wang@huawei.com" Subject: Re: [bug report] GICv4.1: vSGI remains pending across the guest reset In-Reply-To: References: <7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com> <87a5q983zc.wl-maz@kernel.org> <878r5s8xvc.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/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: oliver.upton@linux.dev, jiangkunkun@huawei.com, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, jean-philippe@linaro.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, wanghaibin.wang@huawei.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-20231218_092953_458969_DB938DF2 X-CRM114-Status: GOOD ( 33.18 ) 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 On Mon, 18 Dec 2023 17:20:04 +0000, Oliver Upton wrote: > > On Sun, Dec 17, 2023 at 06:52:55PM +0000, Marc Zyngier wrote: > > On Sun, 17 Dec 2023 17:34:38 +0000, > > Oliver Upton 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? > > Isn't that the case where we have a physical IRQ mapped and wind up > forwarding state to the physical GIC? Indeed. But that's not specific to the timer. That's a general infrastructure that NV also uses it for the GIC maintenance interrupt. > > > 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. > > Fine by me. I had felt like a common helper w/ the user v. guest > exclusions is a bit easier to understand than diffing two very similar > functions, but it isn't a big deal. To be clear, I'm not objecting to that rework. It's just that we should carefully review these patches on the list, as they would have a wider ranging impact than a pure GICv4.1 change. > Anyway, I'm happy with your fix. I'd like Kunkun to give it a go but > either way I can pick it up for 6.7. Yup, same here. But we also shouldn't hold the 6.7 fixes for too long. If we don't get feedback from Kunkun shortly, I'd suggest to move this patch to 6.8, and at this point your approach makes complete sense. 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