> From: Alex Williamson <alex.william...@redhat.com> > Sent: Wednesday, July 29, 2020 3:20 AM > [...] > > + > > +For example, IOTLB invalidations should always succeed. There is no > > +architectural way to report back to the vIOMMU if the UAPI data is > > +incompatible. If that happens, in order to guarantee IOMMU iosolation, > > isolation > > > +we have to resort to not giving completion status in vIOMMU. This may > > +result in VM hang. > > + > > +For this reason the following IOMMU UAPIs cannot fail without > > +catastrophic effect: > > + > > +1. Free PASID > > +2. Unbind guest PASID > > +3. Unbind guest PASID table (SMMU) > > +4. Cache invalidate > > I'm not entirely sure what we're trying to assert here. Clearly cache > invalidation can fail and patch 5/6 goes on to add over a dozen checks > of the user provided data that return an -errno. Any user ioctl can > fail if the user botches the parameters. So are we just trying to > explain the feature checking that should allow the user to know > supported combinations and if they adhere to them, these should not > fail? It's not quite worded to that effect. Thanks, >
I guess the above wording is messed by what a UAPI should behave and whether the vIOMMU reports associated errors. UAPI can always fail, as you pointed out. vIOMMU may not have a matching error code though, e.g. on Intel VT-d there is no error reporting mechanism for cache invalidation. However, it is not wise to assert UAPI behavior according to vIOMMU definition. An error is an error. vIOMMU should just react to UAPI errors according to its architecture definition (e.g. ignore, forward to guest, hang, etc.). From this matter I feel above section could better be removed. Thanks Kevin _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
