On 04/23/2012 06:55 PM, Jan Kiszka wrote: > 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.kiszka@xxxxxxxxxxx> > >> --- > >> > >> 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. Okay, I guess waiting for a grace period in order to queue an interrupt is excessive. > > > > 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? It increases the number of syscalls, and doesn't bound it if new interrupt types (like MSI with source information) becomes available. However, this thinking shouldn't influence the ioctl interface too much. > 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. Well we can do that now, with either interface, since MSIs can be unicast or multicast. > > > > 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. Depends on whether we emulate interrupt remapping in the kernel or userspace. -- 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
