Re: [PATCH] KVM: Introduce generic interrupt injection for in-kernel irqchips

[Jan Kiszka <jan.kiszka@siemens.com>]

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@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