From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Alex Williamson
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Subject: Re: [RFC PATCHv2 0/3] Support for nesting IOMMUs in VFIO
Date: Mon, 14 Jul 2014 18:06:07 +0100 [thread overview]
Message-ID: <20140714170607.GP1779@arm.com> (raw)
In-Reply-To: <1405008845.4256.252.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
On Thu, Jul 10, 2014 at 05:14:05PM +0100, Alex Williamson wrote:
> On Thu, 2014-07-10 at 16:45 +0100, Will Deacon wrote:
> > On Thu, Jul 10, 2014 at 04:38:18PM +0100, Alex Williamson wrote:
> > > On Thu, 2014-07-10 at 12:34 +0100, Will Deacon wrote:
> > > > Do you think that returning something like -EOPNOTSUPP from an attach is
> > > > sufficient for userspace to figure out what's gone wrong?
> > >
> > > It seems like this would all be a little easier if we had some sort of
> > > bus_type iterator, then when we want to see if nesting is supported we'd
> > > iterate the bus_types, test iommu_present(), iommu_domain_alloc(),
> > > iommu_domain_set_attr(), iommu_domain_free(). We'd only allow a nesting
> > > domain to be set if the IOMMU driver for at least one bus_type supports
> > > it. Then I think enforcing it would be a little more obvious to
> > > userspace. There is a bus_kset, but we'd need an iterator or at least
> > > to enable find_bus() and have type1 walk a list of bus names known to
> > > possibly support nesting (uglier, but functional). Thanks,
> >
> > That would work fine if we only had one IOMMU instance per bus. The problem
> > is, the ARM SMMU driver (at least) can handle multiple SMMU instances on a
> > single bus, only some of which may be capable of nesting. Until we've done
> > an attach, it's impossible to know what the capabilities are (since the
> > attach is what binds the domain to a physical IOMMU).
> >
> > So you'd actually need to iterate the bus_type, test iommu_present(),
> > iommu_domain_alloc(), iommu_domain_attach(), iommu_domain_free(). The
> > attach, of course, then requires devices which means you ultimately end up
> > rolling VFIO_SET_IOMMU and VFIO_SET_CONTAINER into a single operation. I
> > don't think that helps the group abstraction much!
>
> I don't really see how that diminishes the value. It still means that
> it's only possible to set the IOMMU type of a container to nesting if
> it's possible to support a nesting IOMMU. The user would get an error
> trying to attach any group to the container that can't be supported as
> nesting, whether that's behind the wrong bus_type or behind the wrong
> IOMMU in the correct bus_type. The iommu-sysfs extensions that recently
> went into the iommu next branch would help to expose this kind of
> information to the user.
>
> It seems like an improvement versus statically advertising support for
> something that actually cannot be enabled. Thanks,
Ok, I suppose it's an improvement. Given that we don't have a bus_type
iterator, would you object if I only do this for the pci_bus_type for now
(i.e. the only bus that's VFIO currently supports).
Will
prev parent reply other threads:[~2014-07-14 17:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-09 18:28 [RFC PATCHv2 0/3] Support for nesting IOMMUs in VFIO Will Deacon
[not found] ` <1404930526-32119-1-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-07-09 18:28 ` [RFC PATCHv2 1/3] iommu: introduce domain attribute for nesting IOMMUs Will Deacon
2014-07-09 18:28 ` [RFC PATCHv2 2/3] vfio/iommu_type1: add new VFIO_TYPE1_NESTING_IOMMU IOMMU type Will Deacon
2014-07-09 18:28 ` [RFC PATCHv2 3/3] iommu/arm-smmu: add support for DOMAIN_ATTR_NESTING attribute Will Deacon
2014-07-09 20:37 ` [RFC PATCHv2 0/3] Support for nesting IOMMUs in VFIO Alex Williamson
[not found] ` <1404938235.4256.199.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2014-07-10 11:34 ` Will Deacon
[not found] ` <20140710113406.GM2449-5wv7dgnIgG8@public.gmane.org>
2014-07-10 15:38 ` Alex Williamson
[not found] ` <1405006698.4256.237.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2014-07-10 15:45 ` Will Deacon
[not found] ` <20140710154510.GV2449-5wv7dgnIgG8@public.gmane.org>
2014-07-10 16:14 ` Alex Williamson
[not found] ` <1405008845.4256.252.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2014-07-14 17:06 ` Will Deacon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140714170607.GP1779@arm.com \
--to=will.deacon-5wv7dgnigg8@public.gmane.org \
--cc=alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).