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

["Mathew, Cherry G." <cherry%zyx.in@localhost>]

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).


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.