All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Prakhya, Sai Praneeth" <sai.praneeth.prakhya@intel.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: "Raj, Ashok" <ashok.raj@intel.com>,
	Will Deacon <will.deacon@arm.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>
Subject: RE: [PATCH 3/4] iommu: Add support to change default domain of an iommu_group
Date: Wed, 4 Sep 2019 03:09:00 +0000	[thread overview]
Message-ID: <FFF73D592F13FD46B8700F0A279B802F4FBECD3E@ORSMSX114.amr.corp.intel.com> (raw)
In-Reply-To: <20190903125046.GA11530@8bytes.org>

Hi Joerg,

Thanks a lot! for the review. I highly appreciate for sparing your time to review the patch :)

> On Tue, Aug 20, 2019 at 07:42:25PM -0700, Sai Praneeth Prakhya wrote:
> > +	/*
> > +	 * iommu_domain_alloc() takes "struct bus_type" as an argument which
> is
> > +	 * a member in "struct device". Changing a group's default domain type
> > +	 * deals at iommu_group level rather than device level and hence there
> > +	 * is no straight forward way to get "bus_type" of an iommu_group that
> > +	 * could be passed to iommu_domain_alloc(). So, instead of directly
> > +	 * calling iommu_domain_alloc(), use iommu_ops from previous default
> > +	 * domain.
> > +	 */
> > +	if (!prev_domain || !prev_domain->ops ||
> > +	    !prev_domain->ops->domain_alloc || !type)
> > +		return -EINVAL;
> 
> Hmm, this isn't really nice and clean, but I understand why you need it.

I agree.. It didn't look good for me either :(
But, I didn't find any other better solution. 

> I will think about a better way to get iommu_ops here.

Sure! That will be great!

> > +free_prev_domain:
> > +	/*
> > +	 * Free the existing default domain and replace it with the newly
> > +	 * created default domain. No need to set group->domain because
> > +	 * __iommu_attach_group() already does it on success.
> > +	 */
> > +	iommu_domain_free(prev_domain);
> > +	group->default_domain = new_domain;
> > +	return 0;
> 
> It isn't obvious to me from this patch, how to are the dma_ops updated when
> the default domain changes between identity and dma?

Thanks for raising this.
For intel_iommu, dma_map_ops is defined at drivers/iommu/intel-iommu.c and
all the callbacks like alloc(), map_sg() and map_page(), check if the device needs DMA mapping or not 
by calling iommu_need_mapping(). The callbacks inherently do the right thing based on the outcome.
So, essentially the dma_ops are same for dma/identity domain.

I just realized (sorry!) that other iommu drivers (Eg: AMD) doesn't do it the same way i.e. looks like the callbacks 
aren't checking if the device needs a dma mapping or identity mapping.
I will take a look at other iommu drivers and will handle this in V2.

Please let me know if I missed something.

> > +	/* Check if any device in the group still has a driver binded to it */
> > +	if (iommu_group_for_each_dev(group, NULL, is_driver_binded)) {
> > +		pr_err("Active drivers exist for devices in the group\n");
> > +		return -EBUSY;
> > +	}
> 
> This is racy with device driver probing code. Unfortunatly there is no clean way
> out of that either, locking all devices in the group and then do the re-attach will
> introduce a lock-inversion with group->mutex. But please put a comment here
> saying that this might race with device driver probing.

Sure! Makes sense. Will add it in V2.

Regards,
Sai
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2019-09-04  3:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-21  2:42 [PATCH 0/4] iommu: Add support to change default domain of a group Sai Praneeth Prakhya
2019-08-21  2:42 ` [PATCH 1/4] iommu/vt-d: Modify device_def_domain_type() to use at runtime Sai Praneeth Prakhya
2019-08-21  2:42 ` [PATCH 2/4] iommu: Add device_def_domain_type() call back function to iommu_ops Sai Praneeth Prakhya
2019-08-21  2:42 ` [PATCH 3/4] iommu: Add support to change default domain of an iommu_group Sai Praneeth Prakhya
2019-09-03 12:50   ` Joerg Roedel
2019-09-04  3:09     ` Prakhya, Sai Praneeth [this message]
2019-09-04  3:17       ` Lu Baolu
2019-09-04 16:18         ` Prakhya, Sai Praneeth
2019-08-21  2:42 ` [PATCH 4/4] iommu: Document usage of "/sys/kernel/iommu_groups/<grp_id>/type" file Sai Praneeth Prakhya
2019-08-21 14:52   ` John Garry
2019-08-21 17:08     ` Sai Praneeth Prakhya

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=FFF73D592F13FD46B8700F0A279B802F4FBECD3E@ORSMSX114.amr.corp.intel.com \
    --to=sai.praneeth.prakhya@intel.com \
    --cc=ashok.raj@intel.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=robin.murphy@arm.com \
    --cc=will.deacon@arm.com \
    /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.