On 2012-04-03 18:54, Avi Kivity wrote: > On 04/03/2012 07:47 PM, Jan Kiszka wrote: >>> >>> so we have a single ioctl for all interrupt handling. This allows >>> eventual removal of the line-oriented ioctls. >>> >>> The other alternative is to have a dma interface, similar to the kvm_run >>> mmio interface but with the kernel acting as destination. The advantage >>> here is that we can handle dma from a device to any kernel-emulated >>> device, not just the APIC MSI range. A downside is that we can't return >>> values related to interrupt coalescing. >> >> Due to lacking injection feedback, I'm in favor of option 1. Will have a >> look. > > I wonder if we can create a side channel for it. Lack of a kernel DMA > API is a hole in the current code, though we haven't been bitten by it > yet. An example is a guest that is swapping its own page tables; right > now the shadow mmu doesn't notice those writes (when the page tables are > swapped in) and will deliver incorrect results. Of course no guest does > that, so it doesn't happen in practice. > >>> >>> A performance note: delivering an interrupt needs to search all vcpus >>> for an APIC ID match. The previous plan was to cache (or pre-calculate) >>> this lookup in the irq routing table. Now it looks like we'll need a >>> separate cache for this. >> >> As this is non-existent until today, we don't regress here. And it can >> still be added on top later on, transparently. > > Yes, it's just a note, not an objection. The cache lookup will be > slower than the gsi lookup (hash table vs. array) but still O(1) vs. the > current O(n). If you are concerned about performance in this path, wouldn't a DMA interface for MSI injection be counterproductive? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
