Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:You are correct. Using the existing irq handling logic will cause us to drop irqs and to loose information if two messages are sent close to each other. Which is very nasty. With a little care we can avoid that problem by having a 32 bit bitmap of which sub irqs have fired so we can make all of them pending without loosing information. That does requires a new handle_irq method. One of the primary purposes of masking irqs in hardware is to prevent them from screaming. Unlikely with edge triggered irqs but not a capability I would like to give up. Multi-msi has the problem that cpu affinity can not be changed on a per message basis without an iommu. Which is a portability problem and a problem on common architectures. Therefore to support multi-msi it must be handled as a special case, we can not treat the individual messages like normal irqs. Eric --
| Parag Warudkar | BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0] |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Arjan van de Ven | Re: [GIT]: Networking |
| David Miller | Re: [BUG] New Kernel Bugs |
