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

[Anthony Liguori]

On Sun, Jun 23, 2013 at 9:07 AM, Michael S. Tsirkin <address@hidden> wrote:
> On Fri, Jun 21, 2013 at 09:51:20AM +1000, Alexey Kardashevskiy wrote:
>> And kvm_irqchip_add_msi_route does not have any link to a device or a bus
>> so I'll have to walk through all PHBs in system and see if PHB's MSI window
>> is the one from MSIMessage and convert MSIMessage to virq. Pretty easy and
>> quick but still dirty hack, would it be better?
>
> Yes I think that's fine really.
>
> Basically devices all speak MSIMessage as they should -
> this is what the PCI spec says.
> On all normal systems guests also speak MSIMessage so
> the API which uses these makes sense for kvm.

There is no difference between Power and x86 in how they handle MSI.
MSI is not a concept in the APIC or processor.  MSI interrupts are
handled by the PHB and delivered through the I/O APIC using the
information in the address/data.

I've always assumed that the kernel knows about MSI just because PCI
passthrough needs it for whatever reason.  It's not part of the APIC
complex and it is weird to have MSI decoding information in the
kernel.

> Except, ppc architecture in its wisdom decided to hide this
> in firmware.  QEMU does not have firmware so the translation
> has to be maintained in QEMU powerpc code.

To be clear: instead of writing to an address with a load/store, Power
has a hypercall to do this.  The hypercall is hidden behind a firmware
abstract layer (RTAS) but it's still just a hypercall.

It uses a hypercall simply because Power was designed to not require
MMIO trapping.  It's much like Xen PV in that regard.

It doesn't make a lot of sense to have Power do MSI decoding in
userspace while x86 does it in the kernel.  I assume the kernel
doesn't have enough information to do the translation on Power?

Regards,

Anthony Liguori

> --
> MST
>