Re: [PATCH 1/2] KVM: arm/arm64: vgic: Don't populate multiple LRs with the same vintid

[Marc Zyngier <marc.zyngier@arm.com>]

Hi Christoffer,

On Fri, 09 Mar 2018 21:39:31 +0000,
Christoffer Dall wrote:
> 
> On Thu, Mar 08, 2018 at 06:39:20PM +0000, Marc Zyngier wrote:
> > Thinking of it a bit more: MI on EOI doesn't offer much more guarantee
> > in the way of priority ordering. Taking your example above: Even if
> > you generate a MI when EOIing the SGI, there is no guarantee that
> > you'll take the MI before you've acked the SPI.
> 
> There's no guarantee, but at least you're attempting at processing the
> SGIs in first.  It's the best we can do, but not completely correct,
> kinda thing...
> 
> > 
> > If you really want to offer that absolute guarantee that all the
> > multi-source SGIs of higher priority are delivered before anything
> > else, then you must make sure that only the SGIs are present in the
> > LRs, excluding any other interrupt on lower priority until you've
> > queued them all.
> 
> Yes, that sucks!  Might not be too hard to implement, it's basically an
> early out of the loop traversing the AP list, but just an annoying
> complication.

Yeah, it is a bit gross. The way I implemented it is by forcing the AP
list to be sorted if there is any multi-SGI in the pipeline, and early
out as soon as we see an interrupt of a lower priority than the first
multi-SGI. That way, we only have an overhead in the case that
combines multi-SGI and lower priority interrupts.

> > At that stage, I wonder if there is a point in doing anything at
> > all. The GICv2 architecture is too rubbish for words.
> > 
> 
> The case we do need to worry about is the guest processing all its
> interrupts and not exiting while there is actually still an SGI pending.
> At that point, we can either do it with the "no interrupts pending
> maintenance interrupt" or with the "EOI maintenance interrupt", and I
> think the latter at least gets us slightly closer to the architecture
> for a non-virtualized system.

I think that this is where we disagree. I don't see anything in the
architecture that mandates that we should present the SGIs before
anything else. All we need to do is to ensure that interrupts of
higher priority are presented before anything else. It is perfectly
acceptable for an implementation to deliver SGI0, then SPI3, and SGI0
(from another CPU) after that, as long as SPI3 isn't of lesser
priority than SGI0.

Another thing I dislike about using EOI for that is forces us to
propagate the knowledge of the multi-SGI horror further down the
stack, down to both implementations of vgic_populate_lr. NPIE allows
us to keep that knowledge local. But that's an orthogonal issue, and
we can further argue/bikeshed about the respective merits of both
solutions once we have something that fits the sorry state of the
GICv2 architecture ;-).

Thanks,

	M.

-- 
Jazz is not dead, it just smell funny.