All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <dwg@au1.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Chris Wright <chrisw@redhat.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	joerg.roedel@amd.com, dwmw2@infradead.org,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	agraf@suse.de, scottwood@freescale.com, B08248@freescale.com
Subject: Re: [PATCH 1/4] iommu: Add iommu_device_group callback and iommu_group sysfs entry
Date: Thu, 1 Dec 2011 13:00:46 +1100	[thread overview]
Message-ID: <20111201020046.GF5427@truffala.fritz.box> (raw)
In-Reply-To: <1322704207.3729.10.camel@pasglop>

On Thu, Dec 01, 2011 at 12:50:07PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2011-11-30 at 17:04 -0800, Chris Wright wrote:
> > Heh.  Put it another way.  Generating the group ID is left up to the
> > IOMMU.  This will break down when there's a system with multiple IOMMU's
> > on the same bus_type that don't have any awareness of one another.  This
> > is not the case for the existing series and x86 hw.
> > 
> > I'm not opposed to doing the allocation and ptr as id (taking care for
> > possibility that PCI hotplug/unplug/replug could reuse the same memory
> > for group id, however).  Just pointing out that the current system works
> > as is, and there's some value in it's simplicity (overloading ID ==
> > group structure + pretty printing ID in sysfs, for example). 
> 
> Well, ID can work even with multiple domains since we have domains
> numbers. bdfn is 16-bit, which leaves 16-bit for the domain number,
> which is sufficient.
> 
> So by encoding (domain << 16) | bdfn, we can get away with a 32-bit
> number... it just sucks.

Except that the iommu group structure is not supposed to be specific
to PCI.

> Note that on pseries, I wouldn't use bdfn anyway, I would use my
> internal "PE#" which is also a number that I can constraint to 16-bits.
> 
> So I can work with a number as long as it's at least an unsigned int
> (32-bit), but I think it somewhat sucks, and will impose gratuituous
> number <-> structure conversions all over, but if we keep the whole
> group thing an iommu specific data structure, then let's stick to the
> number and move on with life.
> 
> We might get better results if we kept the number as
> 
> struct iommu_group_id {
> 	u16	domain;
> 	u16	group;
> };
> 
> (Or a union of that with an unsigned int)
> 
> That way the domain information is available generically (can be match
> with pci_domain_nr() for example), and sysfs can then be layed out as
> 
> /sys/bus/pci/groups/<domain>/<id>
> 
> Which is nicer than having enormous id's
> 
> Cheers,
> Ben.
> 
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson


  reply	other threads:[~2011-12-01  2:00 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-21 19:55 [PATCH 0/4] iommu: iommu_ops group interface Alex Williamson
2011-10-21 19:56 ` [PATCH 1/4] iommu: Add iommu_device_group callback and iommu_group sysfs entry Alex Williamson
2011-11-30  2:42   ` David Gibson
2011-11-30  4:51     ` Benjamin Herrenschmidt
2011-11-30  5:25       ` Alex Williamson
2011-11-30  9:23         ` Benjamin Herrenschmidt
2011-12-01  0:06           ` David Gibson
2011-12-01  6:20           ` Alex Williamson
2011-12-01  0:03         ` David Gibson
2011-12-01  0:52           ` Chris Wright
2011-12-01  0:57             ` David Gibson
2011-12-01  1:04               ` Chris Wright
2011-12-01  1:50                 ` Benjamin Herrenschmidt
2011-12-01  2:00                   ` David Gibson [this message]
2011-12-01  2:05                   ` Chris Wright
2011-12-01  7:28                     ` Alex Williamson
2011-12-01 14:02                     ` Yoder Stuart-B08248
2011-12-01  6:48           ` Alex Williamson
2011-12-01 10:33             ` David Woodhouse
2011-12-01 14:34               ` Alex Williamson
2011-12-01 21:46                 ` Benjamin Herrenschmidt
2011-12-01 22:37                   ` Alex Williamson
2011-12-01 23:14                 ` David Woodhouse
2011-12-07  6:20                   ` Benjamin Herrenschmidt
2011-12-01 21:32             ` Benjamin Herrenschmidt
2011-10-21 19:56 ` [PATCH 2/4] intel-iommu: Implement iommu_device_group Alex Williamson
2011-11-08 17:23   ` Roedel, Joerg
2011-11-10 15:22     ` David Woodhouse
2011-10-21 19:56 ` [PATCH 3/4] amd-iommu: " Alex Williamson
2011-10-21 19:56 ` [PATCH 4/4] iommu: Add option to group multi-function devices Alex Williamson
2011-12-01  0:11   ` David Gibson
2011-10-21 20:34 ` [PATCH 0/4] iommu: iommu_ops group interface Woodhouse, David
2011-10-21 21:16   ` Alex Williamson
2011-10-21 22:39     ` Woodhouse, David
2011-10-21 22:34   ` Alex Williamson
2011-10-27 16:31 ` Alex Williamson
2011-11-15 15:51 ` Roedel, Joerg

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=20111201020046.GF5427@truffala.fritz.box \
    --to=dwg@au1.ibm.com \
    --cc=B08248@freescale.com \
    --cc=agraf@suse.de \
    --cc=alex.williamson@redhat.com \
    --cc=benh@kernel.crashing.org \
    --cc=chrisw@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joerg.roedel@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=scottwood@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 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.