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). -- error compiling committee.c: too many arguments to function -- 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
