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