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. > > 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
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. > > > >> It seems like the only sane way to actually support (2) and (3). > >> > >> Regards, > >> > >> Anthony Liguori > > > > -- > > Gleb.
