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, Alex
