Port-amd64 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



On Wed, Dec 12, 2018 at 06:09:10PM +0530, Mathew, Cherry G. wrote:
> On December 12, 2018 6:02:37 PM GMT+05:30, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
> >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
> 
> Yes, I understand that (the xen port does something similar privately).
> What I don't understand is the concurrency/re-entrancy implications
> this might cause (seeing that the current implementation uses locked prefixes).

It doesn't change anything with regard to updating iplmask/ipllevel. It
just means that the fields are smaller. It would help to avoid the need
for 64bit cmpxchg on i386.

Joerg


Home | Main Index | Thread Index | Old Index