Re: MSI/MSI-X implementation and interrupt handling on i386/amd64

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Wed, Dec 12, 2018 at 07:34:04AM +0530, Mathew, Cherry G. wrote:
> On December 12, 2018 4:29:39 AM GMT+05:30, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
> >On Tue, Dec 11, 2018 at 11:41:35PM +0100, Jaromír Doleček wrote:
> >> Moving this to port-amd64 (bcced current-users@ for reference)
> >> 
> >> Le mar. 11 déc. 2018 à 04:34, Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost> a
> >écrit :
> >> > I mention some old Athlon 64 series (before socket AM2) do not
> >support
> >> > cmpxchg16b instruction. That would affect rewriting spllower to
> >support
> >> > 64 bit interrupt bitmask.
> >> 
> >> Indeed, need to do runtime check for cmpxchg16b support.
> >> 
> >> I'm investigating an initial solution which will keep the
> >> ipending+ilevel still as 64-bit quantity suitable for cmpxchg8b,
> >using
> >> 4 bits for the ilevel and remaining 60 for ipending.
> >> 
> >> The 60/4 split with cmpxchg8b should work for i386 too. Besides
> >> spl.S/vector.S, so far I only found one place using atomic write on
> >> the ipending - clearing interrupt from ipending in intr disestablish.
> >> This one can easily change to just block all interrupts during the
> >> clearing, since this is not performance critical path.
> >
> >The alternative would be to not store a mask of sources, but the max
> >IPL
> >level.
> >
> >Joerg
> 
> The mask is stored to facilitate quick calculation of if a handler can run at a given IPL (calculated in intr.c) . 
> 
> I haven't thought of the race issues if this is moved to something else.

The idea is to essentially change
    intrsource & iplmask
into
    intrmask[intrsource] & iplmask
with iplmask now being only ~10 bits large or just
    intrlevel[intrsource] >= ipllevel
with ipllevel being a small integer.

Joerg