> 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. Cheers, Ben. -- 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
