On Mon, Jun 24, 2013 at 08:34:52AM -0500, Anthony Liguori wrote: > Gleb Natapov <g...@redhat.com> writes: > > > On Mon, Jun 24, 2013 at 07:32:32AM -0500, Anthony Liguori wrote: > >> Gleb Natapov <g...@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. > Not if interrupt remapping is in use.
> 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. > Good that it does that otherwise it would have been broken after interrupt remapping implementation. > Such an interface would also allow for a QEMU implementation of an IO > APIC while still having the in-kernel LAPIC. > Yes. > It would also allow QEMU to do per-device MSI decoding. > Why can't it be done now with existing interfaces? > Isn't this more or less what Avi's previous proposal was around changing > the APIC interfaces to userspace? > Avi actually was against adding KVM_SIGNAL_MSI initially since it duplicated the functionality we already had. Don't remember how Jan managed to persuade him in the end :) -- Gleb.