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 897EF359FA0 for ; Fri, 9 Jan 2026 12:20:19 +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=1767961219; cv=none; b=dMQrbsItUSUgOKYHd+ofLnIBjlhU9IGvC0GZg83qqV3SJJxmoQmT/h60ZnCorEYbiIhRXsa6/IdNWRVZ0srZvBA/mSD4FbyEJQgWDkYNf6jxoKyLFXjXZMr5QTvsJ8p4EqZKqkkOGSd4HnMAFWdsXRqBNuy0wc+60QXVuAt3oHU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767961219; c=relaxed/simple; bh=yQ+YmtCFiYQG7jM784Wk0Pq5AMj7LYg32BsmemRgHKA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=OohiC2wRmjT14Ro1LLKsrByReKVKCsbfYHdhOKtyMmKqh5F3C7sCxP2V+zXMgnIvAdkYwzDfXFSwS7JvfSadbFS9GMmx9VITi6a2FEk+z1YLozACiMvuSJ+yx88NGJ8S9bA7wr6/9pqBqvuXEejEXt2sdf88fNH+emU7zjWQMBA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rZl8LbUF; 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="rZl8LbUF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BAD5DC4CEF1; Fri, 9 Jan 2026 12:20:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767961219; bh=yQ+YmtCFiYQG7jM784Wk0Pq5AMj7LYg32BsmemRgHKA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=rZl8LbUFx+sxrSaUxdMgpXLnpcBh6awsmIHDOaa59zJfMIgfpy63EYvFML5gWL83E r8n9Fnn/4B29ij/ZWTfiFmYV4737VZiExQ9YekrzulEWzkLYZI5M0SjDekRv4eH/CY HEzGLlKUj+9TLe1+pQq1Webv9B1kPcQ9faGVDlpfKGBnmMiok165L2Sq5TwGU6xGoh PLwao75GOlPOj72MlsdWSLC7mTig0IaxvuxRMfFoQ1T9GwrEF2UjBBj2Lohvp9pbCn kOojfYUJOz3KSipkNrvDsbOMd/waxHwBNFpwFF4BgA1zARt4d1lDA4bYtXBkRcO0xf r3oNGFv/9porg== From: Thomas Gleixner To: Luigi Rizzo Cc: Marc Zyngier , bhelgaas@google.com, linux-kernel@vger.kernel.org Subject: Re: [patch 1/2] irqchip/msi-lib: Honor the MSI_FLAG_PCI_MSI_MASK_PARENT flag In-Reply-To: References: <20250903135433.380783272@linutronix.de> <20251220193120.3339162-1-lrizzo@google.com> <87tsxkdp6s.wl-maz@kernel.org> <86ms3amqzm.wl-maz@kernel.org> <871pjzu6wl.ffs@tglx> Date: Fri, 09 Jan 2026 13:20:15 +0100 Message-ID: <878qe7rn9c.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 08 2026 at 22:55, Luigi Rizzo wrote: > On Thu, Jan 8, 2026 at 10:32=E2=80=AFPM Thomas Gleixner wrote: >> >> On Mon, Dec 22 2025 at 16:16, Marc Zyngier wrote: >> >> > > Once we remove the costly readback, is there any remaining reason >> >> > > to overwrite [un]mask_irq() with irq_chip_[un]mask_parent() ? >> >> > >> >> > So you are effectively not masking at all and just rely on hope >> >> > instead. I have the utmost confidence in this sort of stuff. Totall= y. >> >> >> >> I don't understand the above comment. >> >> Masking happens as a result of the PCIe write, >> >> which will eventually reach the device. The presence of the >> >> readback does nothing to accelerate the landing of the write. >> > >> > It doesn't accelerate it. It *guarantees* that the write is observed >> > and has taken effect. It acts as a completion barrier. Without it, the >> > write can be buffered at an arbitrary location in the interconnect, or >> > stored in the device but not acted upon. >> > >> > What you have here is the equivalent of throwing a message in a bottle >> > at sea, and expecting a guaranteed reply. >> >> https://xkcd.com/3150/ > > > The irony is that the change I was commenting about > completely removes masking at the PCI level (ie not even the bottle). > > Anyways, coming back to my secondary point, > which is what does the readback give us, I want to repeat my arguments: > > - knowing that the mask() has landed on the device does not guarantee > that there was not a previously generated MSIx write in transit. > So even with the readback, the interrupt subsystem must be > prepared to handle the pending interrupt (which of course it is). That's not the point. The point is that _after_ the mask has reached the device it is guaranteed that no further interrupts are generated until unmask() is invoked. That's what is required e.g. for writing the MSI message to the device. > - if the concern is that the mask() write may never reach the > device, there is no reason to expect that the unmask() > will be treated differently. Yet, the unmask() has no readback It will reach the device at some random point in time. The queued writes are not lost. They are drained at some point and unmask() does not require an guarantee like mask() does. > - unless I am missing some cases, outside of moderation > the mask() is only ever called on interrupt > shutdown or on affinity migration. Correct. Thanks, tglx