On Wed, Jul 02, 2014 at 11:49:02AM +0100, Will Deacon wrote:
> On Tue, Jul 01, 2014 at 08:28:11PM +0100, Alex Williamson wrote:
> > If we go the route of defining it at allocation time, I'd probably think
> > about adding a new interface, like:
> >
> > iommu_domain_alloc_with_features(struct bus_type *bus, u32 features)
> >
> > Where features is a bitmap
> >
> > #define IOMMU_DOMAIN_FEATURE_NESTING (1U << 0)
> >
> > iommu_domain_alloc(struct bus_type *bus) would then just be a wrapper
> > with features = 0. If an IOMMU driver doesn't support a requested
> > feature, it should fail so we don't have cases like KVM requesting a
> > "HYP" domain when it doesn't need it and the IOMMU drivers don't support
> > it.
> >
> > It would be a lot less intrusive if we could use iommu_domain_set_attr()
> > to enable nesting after allocation though. This could return error if
> > called after the point at which it can be easily enabled.
>
> I'll take another look at set_attr, since I agree that it would be cleaner.
Ok, we quickly end up with a bootstrap problem here:
- We need to know whether the domain is stage-1 or stage-2 before we've
attached any devices to it (since we can have DMA traffic once a
device is attached).
- Until a device is attached, we don't know the specific SMMU instance
backing the domain.
- Until we know the SMMU, we don't know whether or not we can do
nesting, and therefore can't handle set_attr calls.
So the two places we can provide this information are either at domain_alloc
time or at device_attach time. I think the former makes more sense, so I'll
look at adding a new alloc function as you suggest above.
Will
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
