On 2012-04-23 17:32, Avi Kivity wrote: > On 04/10/2012 09:30 PM, Jan Kiszka wrote: >> Currently, MSI messages can only be injected to in-kernel irqchips by >> defining a corresponding IRQ route for each message. This is not only >> unhandy if the MSI messages are generated "on the fly" by user space, >> IRQ routes are a limited resource that user space has to manage >> carefully. >> >> By providing a direct injection path, we can both avoid using up limited >> resources and simplify the necessary steps for user land. This path is >> provide in a way that allows for use with other interrupt sources as >> well. Besides MSIs also external interrupt lines can be manipulated >> through this interface, obsoleting KVM_IRQ_LINE_STATUS. >> >> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> >> --- >> >> This picks up Avi's first suggestion as I still think it is the better >> option to provide a direct MSI injection channel. > > My main objection to the previous patch was that it's not needed; qemu > has to work with older kernels that have neither this nor the other > patch. Given that, why do anything further? It won't be cleaner > because the ugly path will remain for compatibility. > > Is there any concrete problem that this solves, that cannot be solved by > a pure (but ugly) user space solution?
As I explained a few times: We avoid taking the lengthy path in userspace, GSI exhaustion, sporadic routing flushes etc. when running on a modern kernel. The "ugly" part in userspace is rather small as we can refrain from optimizing it. Specifically we do not need to touch QEMU all over the MSI path just for KVM. > > wrt the patch itself, it seems fine. I have to agree that the > single-purpose ioctl looks cleaner (but may be less suitable for a > syscall based API). Why would some MSI-only injection IOCTL be problematic for a syscall model? I rather suspect the generic IOCTL may have some limitations as it /might/ be used for mixing broadcasts with solely VCPU-targeted IRQ injections one day, on some arch. > > Just to add some confusion: is this future proof wrt iommu/interrupt > remapping emulation? If you have a single iommu that intercepts all of > the MSI space then there's no problem, but if there are multiple iommus, > or if some devices are "in front of" the iommu, then we need to identify > the source of the message as well. So we'd need an MBZ field for MSI > injection, which can later be filled with the source ID. We will need hierarchical dispatching, using additional source information. But that information is totally unrelated to the pseudo GSI currently used by KVM for the final delivery step to the APIC bus. In fact, the whole message content can be unrelated as it can be modified and even coalesced with other sources along its way to the KVM injection API. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
