Date:   Mon, 20 Dec 2021 16:48:54 +0000
Message-ID: <874k73w7bd.wl-maz@kernel.org>
From:   Marc Zyngier <maz@kernel.org>
To:     Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc:     linux-kernel@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
        kernel-team@android.com, Jay Chen <jkchen@linux.alibaba.com>
Subject: Re: [PATCH] irqchip/gic-v4: Disable redistributors' view of the VPE table at boot time
In-Reply-To: <20211216190315.GA14220@lpieralisi>
References: <20211216144804.1578566-1-maz@kernel.org>
        <20211216190315.GA14220@lpieralisi>
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/27.1
 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Thu, 16 Dec 2021 19:03:15 +0000,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> 
> On Thu, Dec 16, 2021 at 02:48:04PM +0000, Marc Zyngier wrote:
> > Jay Chen reported that using a kdump kernel on a GICv4.1 system
> > results in a RAS error being delivered when the secondary kernel
> > configures the ITS's view of the new VPE table.
> > 
> > As it turns out, that's because each RD still has a pointer to
> > the previous instance of the VPE table, and that particular
> > implementation is very upset by seeing two bits of the HW that
> > should point to the same table with different values.
> > 
> > To solve this, let's invalidate any reference that any RD has to
> > the VPE table when discovering the RDs. The ITS can then be
> > programmed as expected.
> 
> It makes sense. I believe there is an additional question though,
> related to ITSes sharing the VPE table (SVPET) with RDs.
>
> IIUC, all ITSes within a given affinity (that therefore are sharing the
> VPE table) need to be quiesced before allocating a new VPE table.

Yes, there is that too. I think we need a first pass iterating over
the ITSs and invalidate their VPE table pointers, as they may well be
in a shared state. If they are, the ITSs would be liable to generating
RAS errors as well, just like we just saw when sharing the table
between ITS and RDs.

> Again, I am off the radar for a while and this patch makes sense on its
> own, just raising the question since I was trying to understand whether
> that can be an additional issue to solve on kexec; I will follow up
> on this query.

Yeah, please ping me in the new year if you don't hear from me, and
we'll fix that one too.

> It would be nice to know Alibaba's GIC HW topology if possible.

Indeed.

> Thanks for putting together the fix and merging it.

Thanks,

	M.

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