On 8/22/11 2:49 PM, "Benjamin Herrenschmidt" <benh@xxxxxxxxxxxxxxxxxxx> wrote: > >>> I wouldn't use uiommu for that. >> >> Any particular reason besides saving a file descriptor? >> >> We use it today, and it seems like a cleaner API than what you propose >> changing it to. > > Well for one, we are back to square one vs. grouping constraints. I'm not following you. You have to enforce group/iommu domain assignment whether you have the existing uiommu API, or if you change it to your proposed ioctl(inherit_iommu) API. The only change needed to VFIO here should be to make uiommu fd assignment happen on the groups instead of on device fds. That operation fails or succeeds according to the group semantics (all-or-none assignment/same uiommu). I think the question is: do we force 1:1 iommu/group mapping, or do we allow arbitrary mapping (satisfying group constraints) as we do today. I'm saying I'm an existing user who wants the arbitrary iommu/group mapping ability and definitely think the uiommu approach is cleaner than the ioctl(inherit_iommu) approach. We considered that approach before but it seemed less clean so we went with the explicit uiommu context. > .../... > >> If we in singleton-group land were building our own "groups" which were sets >> of devices sharing the IOMMU domains we wanted, I suppose we could do away >> with uiommu fds, but it sounds like the current proposal would create 20 >> singleton groups (x86 iommu w/o PCI bridges => all devices are partitionable >> endpoints). Asking me to ioctl(inherit) them together into a blob sounds >> worse than the current explicit uiommu API. > > I'd rather have an API to create super-groups (groups of groups) > statically and then you can use such groups as normal groups using the > same interface. That create/management process could be done via a > simple command line utility or via sysfs banging, whatever... -- 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
