Re: [PATCH] Add intr_mask() / intr_unmask() interface to mask / unmask individual interrupt sources

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 16/08/2019 à 04:51, Jason Thorpe a écrit :
> > On Aug 12, 2019, at 7:54 AM, Jason Thorpe <thorpej%me.com@localhost> wrote:
> >
> > > Seems like pic_hwmask only needs to be called when is_mask_count==0.
> >
> > Yes, good catch.  I also noticed a few other places where I should be checking is_mask_count before calling pic_hwunmask, and also realized that I needed to add some code to handle the set_affinity flow ... it's complicated by the fact that an intr_mask()'d interrupt will always be "pending", so some care is needed.  Specifically, before waiting for "pending" to drain out, I now mark the interrupt sources as "distribution-pending" ... so when intr_unmask() comes along, it won't re-enable the source at the hardware if it sees that, but will still force processing of the source if it was marked as interrupt-pending.
>
> Ok, I've made some tweaks -- I still need to do some more testing, but I think the basic x86 version of the changes is basically ready.  Updated diff attached.
>
> > > Note that XENINTRSTUB will also need the same changes.
> >
> > Thanks, I'll take a look at those, too.
>
> So, I took a look at this, and I'm not entirely sure what can / should be done with them.  They seem only superficially related to the regular interrupt stubs.  They don't seem to have any notion of "pending".  Can someone explain to me how these work?
>
> -- thorpej

Note that I never really paid close attention to the way we wire ISRs, so I'm
probably not the right person to ask. For Xen, I have no idea.

One possible problem though:

-	(*pic->pic_hwunmask)(pic, pin);
+	isp->is_distribute_pending = false;
+	if (isp->is_mask_count == 0)

You get interrupted here, intr_mask_xcall() comes in and does is_mask_count++,
then calls pic->pic_hwmask().

+		(*pic->pic_hwunmask)(pic, pin);

Here it gets unmasked but with is_mask_count==1.