--- On Tue, 8/24/10, Grant Grundler <grundler@xxxxxxxxxxxxxxxx> wrote:
> From: Grant Grundler <grundler@xxxxxxxxxxxxxxxx>
> Subject: Re: Fw: Linux mask_msi_irq() question
> To: "Kanoj Sarcar" <kanojsarcar@xxxxxxxxx>
> Cc: linux-pci@xxxxxxxxxxxxxxx
> Date: Tuesday, August 24, 2010, 9:48 PM
> On Thu, Aug 19, 2010 at 11:51:53PM
> -0700, Kanoj Sarcar wrote:
> ...
> > > Now the question: is it truly guaranteed from
> PCI/PCIE
> > > and/or
> > > MSIX specs that the memory read/flush indeed will
> provide a
> > > strong
> > > interrupt reception barrier?
>
> I don't think so.
>
> The MMIO read will only guarantee that the write hit the
> device. An MSI
> could be sent to a different CPU than the one issueing the
> MMIO read
> immediately before the MMIO write is visible to the device.
> There is
> still a race condition here on the host side due to chipset
> issues
> (example Jesse already gave) and state of the CPU handling
> the MSI.
>
> hth,
> grant
>
Hi Grant,
I think there are two different things in play here:
1. Per PCIE or MSIX, is the device supposed to make sure it does
not issue a msix memwrite after it has sent the read completion
for the host's mask read? Alternatively, does each device thru a
vendor unique way, provide a barrier point by which at least
one host cpu knows that no more interrupt messages will creep
out of the device?
2. On a given chipset with N cpus, how does a cpu initiating
the entry mask operation synchronize with the entry's current
destination cpu? What are the various cases here? Interrupt
rebalance? Device deinit? Others?
Kanoj
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
