Messages in this thread | | | Date | Mon, 20 Dec 2021 16:48:54 +0000 | From | Marc Zyngier <> | Subject | Re: [PATCH] irqchip/gic-v4: Disable redistributors' view of the VPE table at boot time |
| |
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.
| |