On Thu, 2016-08-11 at 14:17 -0600, Alex Williamson wrote: > > vfio isn't playing nanny here for the fun of it, part of the reason we > have vpd access functions is because folks have discovered that vpd > registers between PCI functions on multi-function devices may be > shared. So pounding on vpd registers for function 1 may adversely > > affect someone else reading from a different function. A lot more than that may be shared... the bus for example. lots of devices have backdoors into their own BARs, one partition can make its BARs overlap the neighbour function, ... dang ! In the end, PCI assignment at a granularity smaller than a bus cannot be done in a fully air tight way and shouldn't be relied upon in environemnt where the isolation between partitions matters. The only exception here is SR-IOV of course since it's designed specifically so that the VFs can't be messed with. > This is a case > where I feel vfio needs to step in because if that's a user competing > with the host or two users stepping on each other, well that's exactly > what vfio tries to prevent. A driver in userspace or a VM driver can't > very well determine these sorts of interactions when it only has > visibility to a subset of the functions and users and hardware folks > would throw a fit if I extended iommu groups to encompass all the > related devices rather than take the relatively simple step of > virtualizing these accesses and occasionally quirking devices that are > extra broken, as seems to be required here. Thanks, We may want some kind of "strict" vs. "relaxed" model here to differenciate the desktop user wanting to give a function to his/her windows partition and doesn't care about strict isolation vs. the cloud data center. 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
