Alexander Graf <ag...@suse.de> writes: > On 24.06.2013, at 16:31, Anthony Liguori wrote: > >> "Michael S. Tsirkin" <m...@redhat.com> writes: >> >>> On Mon, Jun 24, 2013 at 08:34:52AM -0500, Anthony Liguori wrote: >>>> Gleb Natapov <g...@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. 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. If you make those assumptions, then the APIC protocol looks a lot like an MSI address/data pair. Regards, Anthony Liguori > > > Alex
