[bug report] GICv4.1: vSGI remains pending across the guest reset

[Marc Zyngier]

On Mon, 18 Dec 2023 17:20:04 +0000,
Oliver Upton <oliver.upton at linux.dev> 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 <oliver.upton at 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?
> 
> 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.