<html>
<body>
<font size=3>At 01:39 PM 2/2/2005, Michael S. Tsirkin wrote:<br>
<blockquote type=cite class=cite cite="">Quoting r. Michael Krause
<krause@cup.hp.com>:<br>
> In fact, section 6.1.3 of the PCIe spec
says<br>
> <br>
> "Note that
similarly to physical interrupt signals, the INTx emulation<br>
> mechanism may potentially cause spurious
interrupts that must be handled by<br>
> the system software."<br>
> <br>
> which is conspicuously silent on ordering
issues but seems to me to be<br>
> saying "watch out."<br>
> <br>
> <br>
> It is silent because it is outside the scope of PCIe
technology. The<br>
> informational note is there to act as a warning for those that may
not be<br>
> experienced in designing these types of solutions. <br>
> <br>
> Let's take a step back and focus on what people believe is a problem
for OpenIB<br>
> to solve here. What do people believe is the root cause?<br>
> <br>
> Mike<br>
> <br><br>
Mike, what do you mean by the root cause?<br><br>
If the CPU may start serving the interrupt while DMA is not yet committed
to memory, we may not rely on the<br>
interrupt/DMA ordering, and its irrelevant whether its PCI-express or
chipset issue.</font></blockquote><br>
Every driver needs to deal with spurious interrupts irrespective of
whether it is a a PCIe or chipset issue. A good h/w / s/w design
should not require PIO Read to ascertain whether something real or
spurious happened. If that is the only concern, then it does
not sound like there is any real problem here only clarification of our
reality being sought.<br><br>
Mike</body>
</html>