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

[Anthony Liguori <anthony@codemonkey.ws>]

Gleb Natapov <gleb@redhat.com> writes:

> On Mon, Jun 24, 2013 at 07:32:32AM -0500, Anthony Liguori wrote:
>> Gleb Natapov <gleb@redhat.com> writes:
>> 
>> This should be a per-device mapping, yes.  But I'm not sure that VCPUs
>> should even see anything.  I don't think a VCPU can generate an MSI
>> interrupt by writing to this location.
>> 
> No, and lower 4k of this space is where APIC is mapped as seen from CPU.
>> Is there anything that prevents us from using IRQFDs corresponding to
>> the target of an MSI mapping and get rid of the MSI info in the kernel?
>> 
> Again, you assume that x86 has some pin that MSI triggers. This is not
> the case; address/data is minimum that is needed to inject interrupt
> there (or moving APIC into userspace, since this is where "translation"
> is happening).

An APIC message contains:

1) Destination Mode
2) Delivery mode
3) Level
4) Trigger mode
5) Vector
6) Destination

Which is more or less what the MSI addr/data pair encodes.

But we can certainly have a userspace interface to inject such a message
into the LAPICs.  In fact, this is more or less what KVM_SIGNAL_MSI is
doing except that it's called MSI and encodes things in an addr/pair.

Such an interface would also allow for a QEMU implementation of an IO
APIC while still having the in-kernel LAPIC.

It would also allow QEMU to do per-device MSI decoding.

Isn't this more or less what Avi's previous proposal was around changing
the APIC interfaces to userspace?

Regards,

Anthony Liguori

>
>> It seems like the only sane way to actually support (2) and (3).
>> 
>> Regards,
>> 
>> Anthony Liguori
>
> --
> 			Gleb.