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

[Gleb Natapov <gleb@redhat.com>]

On Mon, Jun 24, 2013 at 10:17:41AM -0500, Anthony Liguori wrote:
> 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.
Why not? MSI is when a PIC device writes something somewhere. This is
what interface provides. Interpretation of MSI data/address as APIC
message is x86 specific and shouldn't even be compiled by other arches.

> 
> 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.
> 
It looks to me that you are arguing that each architecture needs to have
its own logic to deliver MSI interrupt and for some arches current
interface does not provide enough data. I am not arguing with that.

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

--
			Gleb.