On 21.06.2013, at 13:58, Anthony Liguori wrote: > Alexey Kardashevskiy <a...@ozlabs.ru> writes: > >> On 06/21/2013 08:31 PM, Alexander Graf wrote: >>> >>> On 21.06.2013, at 11:22, Alexey Kardashevskiy wrote: >>> >>>> Previously every PCI host bridge implemented its own MSI memory window >>>> in order to catch msi_notify()/msix_notify() calls from various QEMU >>>> MSI-capable devives such as virtio-pci or vfio and redirect them to >>>> the guest via qemu_pulse_irq(). >>> >>> That's how hardware works, no? >>> >>>> >>>> The encoded MSIMessage used to be encoded as: >>>> * .addr - address in a MSI window, this is how QEMU knows which PHB >>>> is the message for; >>>> * .data - number of a device on a specific PHB and vector number. >>>> >>>> As a PHB has a destriptor for every device, and every descriptor has >>>> first IRQ number and the number of IRQs, it can calculate global IRQ >>>> number to use in qemu_pulse_irq(). >>> >>> How does this work on real hardware? >> >> >> I do not understand the question, really. Here we are emulating pHyp which >> is not real hardware and never pretended to be. Our guests do not touch MSI >> records in the config space and use RTAS MSI calls instead. > > But RTAS is implemented as guest code. I suspect it's doing region > access to generate the actual MSI events.
RTAS is actually implemented as a hypercall, which IIRC in our case modifies the PCI config space registers directly. ALex
