On 05.06.2012, at 03:39, Benjamin Herrenschmidt wrote: > >> Yep, that's what I'd suggest as well, add a blacklist to >> pci_intx_mask_supported() so this device returns false and we require an >> exclusive interrupt for it. Thanks, > > BTW, we should consider supporting an MSI-only option for guests as > well: > > LSIs are a problem for virtualization, especially when we start > having things like expander racks with slots behind bridges etc, and > in some case it's better to support an MSI only setup rather than > not support the virtualizing the devices at all (or at least in > different partitions). > > However, to do that, we either need to ensure the device can't be > coerced by SW to still assert the LSI and cause trouble. This can be > dealt with two ways I have in mind: > > - If we don't use any of those 4 interrupts lines at all (ie, we use no > LSI on the host bridge and they aren't shared with another bridge > etc...), we can just mask them out in the main PIC. On Power there's no > sharing between interrupt sources from different host bridges so that > would work for us > > - If the intermediary P2P bridge has a feature to block incoming LSIs > from children (I've heard that exists, is that standard ? I haven't > looked in the latest specs) > > There's a third one: > > - If you trust the device own mask bit > > ... But this is fishy since many devices -will- have some kind of > backdoor via MMIO to bypass (or alter) the config space setting. In some > cases the driver can even completely replace the firmware inside the > device and do pretty much whatever it wants :-) > > The main thing is how do we "represent" both in term of interface to > qemu and qemu -> kernel interface wanting such a "no LSI" setup... not > sure about that one. Wouldn't the "no LSI" setting be a flag to the vfio configuration? So when you set up the device group, you say "this group can only do MSI". That way the interface would be sysfs and QEMU wouldn't have anything to do with it :) Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
