linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: stuart.yoder@freescale.com, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org, scottwood@freescale.com,
	Varun Sethi <Varun.Sethi@freescale.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
Date: Wed, 03 Apr 2013 12:01:31 -0600	[thread overview]
Message-ID: <1365012091.2882.252.camel@bling.home> (raw)
In-Reply-To: <20130402161812.GI15687@8bytes.org>

On Tue, 2013-04-02 at 18:18 +0200, Joerg Roedel wrote:
> Cc'ing Alex Williamson
> 
> Alex, can you please review the iommu-group part of this patch?

Sure, it looks pretty reasonable.  AIUI, all PCI devices are below some
kind of host bridge that is either new and supports partitioning or old
and doesn't.  I don't know if that's a visibility or isolation
requirement, perhaps PCI ACS-ish.  In the new host bridge case, each
device gets a group.  This seems not to have any quirks for
multifunction devices though.  On AMD and Intel IOMMUs we test
multifunction device ACS support to determine whether all the functions
should be in the same group.  Is there any reason to trust multifunction
devices on PAMU?

I also find it curious what happens to the iommu group of the host
bridge.  In the partitionable case the host bridge group is removed, in
the non-partitionable case the host bridge group becomes the group for
the children, removing the host bridge.  It's unique to PAMU so far that
these host bridges are even in an iommu group (x86 only adds pci
devices), but I don't see it as necessarily wrong leaving it in either
scenario.  Does it solve some problem to remove them from the groups?
Thanks,

Alex

  parent reply	other threads:[~2013-04-03 18:01 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-28 19:53 [PATCH 0/5 v11] iommu/fsl: Freescale PAMU driver and IOMMU API implementation Varun Sethi
2013-03-28 19:53 ` [PATCH 1/5 v11] iommu/fsl: Make iova dma_addr_t in the iommu_iova_to_phys API Varun Sethi
2013-03-28 19:53 ` [PATCH 2/5 v11] powerpc: Add iommu domain pointer to device archdata Varun Sethi
2013-04-02 15:08   ` Joerg Roedel
2013-04-03  5:17     ` Sethi Varun-B16395
2013-04-11 18:16   ` Kumar Gala
2013-06-20 14:29     ` Sethi Varun-B16395
2013-06-20 14:41       ` joro
2013-03-28 19:54 ` [PATCH 3/5 v11] iommu/fsl: Add the window permission flag as a parameter to iommu_window_enable API Varun Sethi
2013-03-28 19:54 ` [PATCH 4/5 v11] iommu/fsl: Add additional iommu attributes required by the PAMU driver Varun Sethi
2013-04-02 15:10   ` Joerg Roedel
2013-04-03  5:21     ` Sethi Varun-B16395
2013-04-03  8:08       ` Joerg Roedel
2013-03-28 19:54 ` [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation Varun Sethi
2013-04-02 15:29   ` Yoder Stuart-B08248
2013-04-02 16:18   ` Joerg Roedel
2013-04-03  1:35     ` Timur Tabi
2013-04-03  1:52       ` Scott Wood
2013-04-03  5:12         ` Sethi Varun-B16395
2013-04-03 15:55           ` Yoder Stuart-B08248
2013-04-03  7:01     ` Sethi Varun-B16395
2013-04-03 18:01     ` Alex Williamson [this message]
2013-04-04 13:00       ` Sethi Varun-B16395
2013-04-04 15:22         ` Alex Williamson
2013-04-04 16:35           ` Sethi Varun-B16395
2013-04-04 16:43             ` Alex Williamson
2013-04-05  0:01               ` Sethi Varun-B16395
2013-04-04 16:43           ` Yoder Stuart-B08248
2013-04-02 16:23 ` [PATCH 0/5 v11] iommu/fsl: Freescale PAMU driver and IOMMU API implementation Joerg Roedel
2013-04-02 17:50   ` Sethi Varun-B16395

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=1365012091.2882.252.camel@bling.home \
    --to=alex.williamson@redhat.com \
    --cc=Varun.Sethi@freescale.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=scottwood@freescale.com \
    --cc=stuart.yoder@freescale.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 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).