On Tue, 2016-08-16 at 08:23 +1000, Benjamin Herrenschmidt wrote: > > I don't think desktop users appreciate hangs any more than anyone else, and > > that is one of the symptoms that can arise here without the vfio > > coordination. > > And can happen with it as well.... Oh and your response was completely besides the point I was trying to make, just some passive aggressive noise, thank you. The point was that if you want the sort of safety that we are trying to aim for, without additional HW support, you basically have to do the isolation on a granularity no smaller than a bridge/bus (with the notable exception of SR-IOV of course). Otherwise guest *will* be able to harm each other (or the host) in all sorts of ways if anything because devices will have MMIO backdoors into their own BAR space, or can be made to DMA to a neighbour, etc... This is the only safe thing to do (and we are enforcing that on POWER with our IOMMU groups). Now that being said, if you want to keep the ability to assign 2 functions of a device to different guests for your average non-critical desktop user, that's where you may want to consider two models. Generally speaking, filtering things for "safety" won't work. Filtering things to work around bugs in existing guests to avoid crashes is a different kettle of fish and could be justified but keep in mind that in most cases a malicious guest will be able to exploit those HW flaws. Assuming that a device coming back from a guest is functional and not completely broken and can be re-used without a full PERST or power cycle is a wrong assumption. It may or may not work, no amount of "filtering" will fix the fundamental issue. If your HW won't give you access to PERST well ... blame Intel for not specifying a standard way to generate it in the first place :-) Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
