All of lore.kernel.org
 help / color / mirror / Atom feed
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: Thu, 10 Jul 2014 12:34:06 +0100	[thread overview]
Message-ID: <20140710113406.GM2449@arm.com> (raw)
In-Reply-To: <1404938235.4256.199.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>

Hey Alex,

On Wed, Jul 09, 2014 at 09:37:15PM +0100, Alex Williamson wrote:
> On Wed, 2014-07-09 at 19:28 +0100, Will Deacon wrote:
> > Hello,
> > 
> > This is v2 of the RFC I originally posted here:
> > 
> >  RFCv1: http://permalink.gmane.org/gmane.linux.kernel.iommu/5552
> > 
> > It's changed significantly since then, based on helpful feedback from
> > Alex. In particular, I no longer butcher the IOMMU API, instead making
> > use of a new iommu_attr to indicate that a domain requires support for
> > nesting.
> > 
> > All feedback welcome (this is still an RFC after all),
> 
> It's a lot cleaner this way, but I'm concerned that allowing a "nesting"
> IOMMU to be created and used just like a TYPE1v2 IOMMU, even if the
> IOMMU doesn't support it, puts us in a corner for compatibility later.
> The safer approach might be to fail the attach_group function if we
> can't set the domain attribute, ie. enforce that the IOMMU must support
> it. 

I also contemplated this (and was my source of confusion when we were
discussing using iommu_attr before), however from a user's perspective it's
not at all clear what's gone wrong. Essentially, VFIO would advertise
support for VFIO_TYPE1_NESTING_IOMMU but any attempt to VFIO_SET_IOMMU
for a container would fail. Knowing to try and fall-back on VFIO_TYPE1v2_IOMMU
isn't at all obvious.

> I don't know how you'd handle it if only some of the domains within
> a container supported it, so enforcement may simplify things down the
> road too.  We wouldn't need the vfio_domains_have_iommu_nesting()
> function that way either.

Agreed, it would certainly make things simpler in the kernel. Although, if
we allow a subset of domains in a container to use nesting, I think that's
possible by only allowing groups in those domains to be part of the virtual
SMMU interface.

Do you think that returning something like -EOPNOTSUPP from an attach is
sufficient for userspace to figure out what's gone wrong?

Will

  parent reply	other threads:[~2014-07-10 11:34 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 [this message]
     [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

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=20140710113406.GM2449@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.