DragonFly BSD
DragonFly kernel List (threaded) for 2006-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: MSI prototype


From: "Chuck Tuffli" <ctuffli@xxxxxxxxx>
Date: Tue, 21 Feb 2006 12:51:07 -0800

Matt -

Thanks for the feedback. More questions and a couple of answers below

On 2/21/06, Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:
. .
>     I think (3) isn't a big deal if the MSI irq abstraction is given
>     the 'number of vectors' required and returns just the base vector,
>     letting the driver do base+0, base+1, base+2 for the individual
>     vectors.  One resource would thus represent all N requested contiguous
>     IRQs.

That sounds fine for MSI, but how do you handle MSI-X which doesn't
have the same restriction for contiguous vectors? I can easily imagine
having a fragmented vector space in which there are enough available
vectors to satisfy a MSI-X request, but none of the vectors are
contiguous so the allocation fails. This would defeat one of the big
advantages of MSI-X over MSI. So I'm suspicious that we would still
want multiple interrupt resources.

>     Reservation and allocation can be solved by removing the software
>     limits on the number of supported IRQs.  In 1.4 I separated out the

I'm not totally sure I follow how this fixes the problem, so let me
ask a follow up question. Are you thinking that the bus driver would
pre-assign all the vectors each device can use? I can imagine this
being one approach to (1), but does this fix (2) as well?

. ..
>     My understanding of MSI(X) is that it basically treats the interrupt
>     as edge-triggered.  On trigger it writes the specified data to the

Yup

>     specified address which, I assume, would be an IOAPIC or LAPIC address?

LAPIC (0xfee00000 + 0xXXX)

>     I can't imagine how it would work with an IOAPIC with its stupid
>     register window crap, so I assume the MSI(X) address and data would
>     inject an ICR command into the LAPIC.  I don't quite understand how
>     the device is able to do that without polling the 'S'end Pending
>     bit in the ICR, though.

My guess is that the memory controller clues the processor into what
is happening out-of-band. Since all the messages are written to
essentially the same address, the memory controller decodes this
address as an interrupt (vs a normal memory access) and passes the 16
bit data (which includes the vector) to the processor.

---chuck




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