On Sat, 2013-06-22 at 00:12 +0200, Alexander Graf wrote: > On 21.06.2013, at 23:54, Benjamin Herrenschmidt wrote: > > > On Fri, 2013-06-21 at 15:46 +0200, Alexander Graf wrote: > >> Not sure. We could just declare a "direct virq==irq" mode in which > >> msi.data == virq == irq. No need for any translation then. > > > > Maybe. Beware that MSI data is only 16-bit on the wire but we may > not > > care here. > > > > One thing I'm not 100% certain of is how Alexey makes all that work > with > > VFIO since the MSI address/data in the device shall not be the qemu > > "cooked up" ones, but the real HW ones (corresponding to a different > > host interrupt). > > > > How do that work ? > > The real device address/data go to a normal host interrupt vector.
Right, I know that :-) > Once we hit such a vector, we need to find out that it's destined for > the guest in real mode - no idea how you planned to do that - and then > reinject it back into the guest with the virtual irq vector that you > can find out by asking the irqfd hopefully. > > It might make sense to implement it the easy way without real mode > first, and then take it from there ;). We have that already. That isn't my question. How is the "configuration" done ? On x86, I assume, the guest kernel directly whacks the MSI config space and MSI-X BAR space using some address/data it cooks up which are *not* the real ones needed in the HW right ? So qemu seems to play tricks to intercept the MSI-X BAR, I swa that, but how does it know what real value to put in the HW instead ? In our case, the guest calls RTAS, which needs to configure "something" in the device. What does it do ? Does it call into VFIO which then does a pci_enable_msi[x] ? In that case how do you deal with a guest for example prodding a single MSI-X in the middle of the array ? This is not an interface supported by pci_enable_msix .... Cheers, Ben.
