Re: [PATCH 2/2] rust: add bindings for interrupt sources

[Philippe Mathieu-Daudé]

On 22/11/24 09:32, Paolo Bonzini wrote:
> > > +/// Interrupt sources are used by devices to pass changes to a boolean value to
> > > +/// other devices (typically interrupt or GPIO controllers).  QEMU interrupt
> > > +/// sources are always active-high.
> >
> > So 'always active-high' = true below? (Wondering about pulsation, if the
> > true -> false transition is always correct).
>
> Yeah, I mean that raise uses true (or 1 :)) and lower uses false.
> an example?

I was thinking of an active-low line where you want to pulse 1 -> 0.
Just chiming in, not to worry about.

> > Is this deliberate to restrict the Rust binding to boolean? (Maybe you
> > envision a VectoredInterruptSource implementation for that).
>
> No, I simply wasn't aware of that.  I'll adjust; do you have
> an example?

I am having hard time to find one, in particular because I
removed one in c264c074d8 ("hw/intc: Remove TYPE_ETRAX_FS_PIC device"):

-static void pic_update(struct etrax_pic *fs)
-{
-    uint32_t vector = 0;
-    int i;
-
-    fs->regs[R_R_MASKED_VECT] = fs->regs[R_R_VECT] & fs->regs[R_RW_MASK];
-
-    /* The ETRAX interrupt controller signals interrupts to the core
-       through an interrupt request wire and an irq vector bus. If
-       multiple interrupts are simultaneously active it chooses vector
-       0x30 and lets the sw choose the priorities.  */
-    if (fs->regs[R_R_MASKED_VECT]) {
-        uint32_t mv = fs->regs[R_R_MASKED_VECT];
-        for (i = 0; i < 31; i++) {
-            if (mv & 1) {
-                vector = 0x31 + i;
-                /* Check for multiple interrupts.  */
-                if (mv > 1)
-                    vector = 0x30;
-                break;
-            }
-            mv >>= 1;
-        }
-    }
-
-    qemu_set_irq(fs->parent_irq, vector);
-}

See Peter's comment in 
https://lore.kernel.org/qemu-devel/CAFEAcA9cObnb11cSS_StbSHdP0aB6sDeqSHfjb3-qRBfy7K9Kw@mail.gmail.com/

> > > +/// Interrupt sources can only be triggered under the Big QEMU Lock; they are
> > > +/// neither `Send` nor `Sync`.
>
> Oops, this is incorrect.  BqlCell *is* Send/Sync, but checks the
> BQL state at run-time.
>
> Paolo