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 PATCH 1/3] iommu: introduce IOMMU_DOMAIN_HYP domain type for hypervisor allocation
Date: Wed, 2 Jul 2014 19:57:42 +0100	[thread overview]
Message-ID: <20140702185742.GQ24879@arm.com> (raw)
In-Reply-To: <1404313455.1862.34.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>

On Wed, Jul 02, 2014 at 04:04:15PM +0100, Alex Williamson wrote:
> On Wed, 2014-07-02 at 14:57 +0100, Will Deacon wrote:
> > 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.
> 
> I don't really see how using set_attr to set a domain parameter is any
> different than specifying it at domain_alloc.  "Create a domain, set it
> to require nesting, add devices" versus "Create a domain and set it to
> require nesting, add devices".  Thanks,

There's a difference in where you detect the error, but actually, that's all
under the same VFIO ioctl so I think you're right.

I'll put together a patch.

Will

      parent reply	other threads:[~2014-07-02 18:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-01 16:10 [RFC PATCH 1/3] iommu: introduce IOMMU_DOMAIN_HYP domain type for hypervisor allocation Will Deacon
     [not found] ` <1404231017-10856-1-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-07-01 16:10   ` [RFC PATCH 2/3] vfio/iommu_type1: add new VFIO_TYPE1_HYP_IOMMU IOMMU type Will Deacon
2014-07-01 16:10   ` [RFC PATCH 3/3] iommu/arm-smmu: add support for IOMMU_DOMAIN_HYP flag Will Deacon
2014-07-01 17:42   ` [RFC PATCH 1/3] iommu: introduce IOMMU_DOMAIN_HYP domain type for hypervisor allocation Alex Williamson
     [not found]     ` <1404236553.3225.93.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2014-07-01 18:04       ` Will Deacon
     [not found]         ` <20140701180426.GX28164-5wv7dgnIgG8@public.gmane.org>
2014-07-01 19:28           ` Alex Williamson
     [not found]             ` <1404242891.3225.144.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2014-07-02 10:49               ` Will Deacon
     [not found]                 ` <20140702104902.GH18731-5wv7dgnIgG8@public.gmane.org>
2014-07-02 13:57                   ` Will Deacon
     [not found]                     ` <20140702135742.GC24879-5wv7dgnIgG8@public.gmane.org>
2014-07-02 15:04                       ` Alex Williamson
     [not found]                         ` <1404313455.1862.34.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2014-07-02 18:57                           ` 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=20140702185742.GQ24879@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.