Re: [Qemu-devel] [PATCH] RFC kvm irqfd: add directly mapped MSI IRQ support

[Anthony Liguori <anthony@codemonkey.ws>]

Alexander Graf <agraf@suse.de> writes:

> On 24.06.2013, at 16:31, Anthony Liguori wrote:
>
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>> 
>>> On Mon, Jun 24, 2013 at 08:34:52AM -0500, Anthony Liguori wrote:
>>>> Gleb Natapov <gleb@redhat.com> writes:
>>>> 
>>>> Isn't this more or less what Avi's previous proposal was around changing
>>>> the APIC interfaces to userspace?
>>>> 
>>>> Regards,
>>>> 
>>>> Anthony Liguori
>>> 
>>> While that's not very elegant, I think we can use the existing
>>> interface for this: just encode things in a fake
>>> "msi message" in the format that kernel expects.
>> 
>> This is, in fact, exactly what we do today.  The MSI interfaces aren't
>> for MSI.  They are for sending messages to the APIC bus.  What we should
>> do is:
>> 
>> #define KVM_SIGNAL_LAPIC	KVM_SIGNAL_MSI
>> #define KVM_IRQ_ROUTING_LAPIC	KVM_IRQ_ROUTING_MSI
>> 
>> And switch to using the new #defines in QEMU.  That would make it more
>> obvious where we need to refactor things.  We currently hard code
>> routing via a local APIC with MSI.  We need to change this into a bus
>> specific function that can choose the right interface.
>> 
>> I think Power is fine with just doing all routing through the irqchip
>> interface.  We may need other routing interfaces for other architectures
>> though.
>
> I'm not quite sure what problem exactly you're trying to solve
> here. The main user of MSI injects through irqfd are in the kernel and
> definitely want a fast path to inject those without any involvement of
> QEMU at all.

Internally the communication between the IO APIC and LAPICs uses a
protocol that does not map to a simple "pin numbering".

Because we implement the IO APIC in the kernel, the kernel interface can
be pin numbering more or less.

But MSI bypasses the IO APIC (potentially at least) which means that we
need a userspace interface for sending APIC messages.

Unfortunately, when this was added to support MSI, this was called "MSI"
but it is most certainly not.

In the very least, you also need the bus state + the source device to do
proper MSI translation.  We get around this by assigning global MSI
addresses and only having a single PHB.

If you make those assumptions, then the APIC protocol looks a lot like
an MSI address/data pair.

Regards,

Anthony Liguori

>
>
> Alex