Re: Potential source of interrupt aliasing

Andrew Gallatin wrote:
> Scott Long writes:
>  > 
>  > See also: sbus(4), msi(4).
>  > 
>  > MSI is something that I'd like to work on, but simply had the time.
>  > It's not a panacea since it will only work for MSI-enabled PCI devices,
>  > but many peripherals found on these Intel systems fall into that
>  > category.
> 
> Bear in mind that MSI is another can of worms.  
> 
> I spent some time last month getting MSI interrupts working for our
> linux driver.  I had the misfortune to start with a system
> (ServerWorks GC-SL based) which did not even support MSIs, but where
> linux let my driver enable MSI operation and allocate MSI interrupts.
> Any DMA to the address given by the linux MSI code resulted in a PCI
> master abort.  That was not fun..
> 
> If/when we do MSI support, I really hope we do a better job of determining
> if MSIs actually work before enabling them ;)
> 
> Drew
> 
> 
> 

I'm a little confused by this.  Between the Intel architecture manuals
and the PCI specs, it seems like MSI is a function of the PCI device
mastering a 32 or 64-bit word into a specific location in host memory.
On the intel architecture, that location is in an area that the L-APICs
will sniff and treat as a kind of virtual IOAPIC.  Maybe you're not
actually hitting real RAM and instead there is Host Bridge magic going
on, but the Intel manuals don't really talk at all about that.  The
Linux MSI support was written by Intel so I'm sure they tailored it for
Intel chipsets and didn't care much about ServerWorks chipsets.  Maybe
this is yet another reason why we need to start seriously thinking about
chipset drivers in FreeBSD.

Scott