On Fri, Aug 27, 2010 at 01:46:38AM -0700, Kanoj Sarcar wrote: ... > I think for both the above points, its hard (if not impossible) > to be sure that all devices that Linux currently supports provide > the expected behavior under all traffic patterns. The conservative > approach would be for platform or generic kernel code to protect > itself against such devices. Agreed. > > IPI is one mechanism. When the second processor completes > > the IPI > > sent from the first processor, we know the second processor > > has > > done whatever we've asked it to do. TLB flushes are > > handled this > > way on some arches for example. > > Probably would work on most architectures, except some complicated > ones. TLB flush only involves processor to processor communication, > but intr masking involves processor to processor, device to cpu A > and device to cpu B communication. Here cpu A initiates intr masking, > and cpu B is the current intr destination. If A<->B path communication > happens faster than device->RC->B path, there is a potential issue. > > I think some of these problems can be handled if A ships the masking > operation (and mask readback/flush from device) over to B thru ipi, > and B responds back to A either thru ipi or coherent memory. Yes, using the IPI to forward the handling is sort of what I had in mind. Just guessing, I suspect one could just leave the MSI enabled on the device and the host low level interrupt handler could queue up the messages until the host or driver "unmasked" again. Then generate another IPI to service the queued messages. Given MSI are e"edge-triggered", they are NOT supposed to generate additional MSI until the previous one is ACKd by the device driver. I do NOT know if this is already happening or what the issues are with this. I'm sure it's not as simple as it sounds. (e.g. ordering of different MSI from same device). hth, grant -- 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
