On Fri, 24 Jul 2020 19:17:49 +0000 Alex wrote: > On Fri, 24 Jul 2020 12:57:49 +0000 > WeitaoWang-oc <WeitaoWang-oc@xxxxxxxxxxx> wrote: > > > On Thu, 23 Jul 2020 12:38:21 -0400, Alan wrote: > > > On Thu, Jul 23, 2020 at 10:17:35AM -0600, Alex Williamson wrote: > > > > The IOMMU grouping restriction does solve the hardware issue, so long > > > > as one driver doesn't blindly assume the driver private data for > > > > another device and modify it. > > > > > > Correction: The IOMMU grouping restriction solves the hardware issue for > > > vfio-pci. It won't necessarily help if some other driver comes along > > > and wants to bind to this hardware. > > > > > > > I do agree that your solution would > > > > work, requiring all devices are unbound before any can be bound, but it > > > > also seems difficult to manage. The issue is largely unique to USB > > > > AFAIK. On the other hand, drivers coordinating with each other to > > > > register their _private_ data as share-able within a set of drivers > > > > seems like a much more direct and explicit interaction between the > > > > drivers. Thanks, > > > > > > Yes, that makes sense. But it would have to be implemented in the > > > driver core, not in particular subsystems like USB or PCI. And it might > > > be seen as overkill, given that only UHCI/OHCI/EHCI devices require this > > > sort of sharing AFAIK. > > > > > > Also, when you think about it, what form would such coordination among > > > drivers take? From your description, it sounds like the drivers would > > > agree to avoid accessing each other's private data if the proper > > > registration wasn't in place. > > > > > > On the other hand, a stronger and perhaps more robust approach would be > > > to enforce the condition that non-cooperating drivers are never bound to > > > devices in the same group at the same time. That's basically what I'm > > > proposing here -- the question is whether the enforcement should be > > > instituted in the kernel or should merely be part of a standard protocol > > > followed by userspace drivers. > > > > > > Given that it's currently needed in only one place, it seems reasonable > > > to leave this as a "gentlemen's agreement" in userspace for the time > > > being instead of adding it to the kernel. > > > > > > > Provided that EHCI and UHCI host controller declare not support P2P and > > ACS. So, we can assign EHCI and UHCI host controller to different IOMMU > > group separately. We assign EHCI host controller to host and assign UHCI > > host controller to VM. Then, ehci_hcd driver load/unload operation in host > > will cause the same issue as discussed > > And you have an example of such a device? I expect these do not exist, > nor should they. It seems like it would be an improper use of ACS. > Thanks, In kernel source code tree drivers/pci/quirks.c, There is a device list declared by pci_dev_acs_enabled. In which list, such as multi-function device without acs capability not allow peer-to-peer bewteen functions. Those device can be assign to to different IOMMU group separately. Thnaks weitao
