All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roedel, Joerg" <Joerg.Roedel-5C7GfCeVMHo@public.gmane.org>
To: Alex Williamson
	<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Florian Dazinger
	<florian-Q0TRQrZM+Zzk1uMJSBkQmQ@public.gmane.org>,
	iommu
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: 3.6-rc7 boot crash + bisection
Date: Wed, 26 Sep 2012 17:10:44 +0200	[thread overview]
Message-ID: <20120926151044.GE10549@amd.com> (raw)
In-Reply-To: <1348670159.28860.183.camel-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>

On Wed, Sep 26, 2012 at 08:35:59AM -0600, Alex Williamson wrote:
> Hmm, that throws a kink in iommu groups.  So perhaps we need to make an
> alias interface to iommu groups.  Seems like this could just be an extra
> parameter to iommu_group_get and iommu_group_add_device (empty in the
> typical case).  Then we have the problem of what's the type for an
> alias?  For AMI-Vi, it's a u16, but we need to be more generic than
> that.  Maybe iommu groups should just treat it as a void* so iommus can
> use a pointer to some structure or a fixed value like a u16 bus:slot.
> Thoughts?

Good question. The iommu-groups are part of the IOMMU-API, with an
interface to the IOMMU drivers and one to the users of IOMMU-API. So the
alias handling itself should be a function of the interface to the IOMMU
driver. In general the interface should not be bus specific.

So a void pointer seems the only logical choice then. But I would not
limit its scope to alias handling. How about making it a bus-private
pointer where IOMMU driver store bus-specific information. That way we
make sure that there is one struct per bus-type for this pointer, and
not one structure per IOMMU driver.


	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

WARNING: multiple messages have this Message-ID (diff)
From: "Roedel, Joerg" <Joerg.Roedel@amd.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Florian Dazinger <florian@dazinger.net>,
	<linux-kernel@vger.kernel.org>,
	iommu <iommu@lists.linux-foundation.org>
Subject: Re: 3.6-rc7 boot crash + bisection
Date: Wed, 26 Sep 2012 17:10:44 +0200	[thread overview]
Message-ID: <20120926151044.GE10549@amd.com> (raw)
In-Reply-To: <1348670159.28860.183.camel@bling.home>

On Wed, Sep 26, 2012 at 08:35:59AM -0600, Alex Williamson wrote:
> Hmm, that throws a kink in iommu groups.  So perhaps we need to make an
> alias interface to iommu groups.  Seems like this could just be an extra
> parameter to iommu_group_get and iommu_group_add_device (empty in the
> typical case).  Then we have the problem of what's the type for an
> alias?  For AMI-Vi, it's a u16, but we need to be more generic than
> that.  Maybe iommu groups should just treat it as a void* so iommus can
> use a pointer to some structure or a fixed value like a u16 bus:slot.
> Thoughts?

Good question. The iommu-groups are part of the IOMMU-API, with an
interface to the IOMMU drivers and one to the users of IOMMU-API. So the
alias handling itself should be a function of the interface to the IOMMU
driver. In general the interface should not be bus specific.

So a void pointer seems the only logical choice then. But I would not
limit its scope to alias handling. How about making it a bus-private
pointer where IOMMU driver store bus-specific information. That way we
make sure that there is one struct per bus-type for this pointer, and
not one structure per IOMMU driver.


	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632


  parent reply	other threads:[~2012-09-26 15:10 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-24 19:03 3.6-rc7 boot crash + bisection Florian Dazinger
2012-09-25 18:32 ` Alex Williamson
2012-09-25 18:42   ` Alex Williamson
2012-09-25 18:54   ` Florian Dazinger
     [not found]     ` <20120925205420.0a07dea2-mGxavARqDwv/PtFMR13I2A@public.gmane.org>
2012-09-25 19:43       ` Alex Williamson
2012-09-25 19:43         ` Alex Williamson
2012-09-25 23:01         ` Florian Dazinger
     [not found]           ` <20120926010154.49cc2588-mGxavARqDwv/PtFMR13I2A@public.gmane.org>
2012-09-26  3:12             ` Alex Williamson
2012-09-26  3:12               ` Alex Williamson
2012-09-26 14:43             ` Roedel, Joerg
2012-09-26 14:43               ` Roedel, Joerg
     [not found]               ` <20120926144345.GC10549-5C7GfCeVMHo@public.gmane.org>
2012-09-26 14:52                 ` Alex Williamson
2012-09-26 14:52                   ` Alex Williamson
2012-09-26 15:04                   ` Roedel, Joerg
2012-09-26 15:04                     ` Roedel, Joerg
     [not found]                     ` <20120926150407.GD10549-5C7GfCeVMHo@public.gmane.org>
2012-09-26 16:13                       ` Alex Williamson
2012-09-26 16:13                         ` Alex Williamson
2012-09-26 16:43                       ` Florian Dazinger
2012-09-26 16:43                         ` Florian Dazinger
2012-09-26 17:47                       ` Florian Dazinger
2012-09-26 17:47                         ` Florian Dazinger
     [not found]         ` <1348602226.28860.132.camel-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2012-09-26 13:20           ` Roedel, Joerg
2012-09-26 13:20             ` Roedel, Joerg
     [not found]             ` <20120926132050.GB10549-5C7GfCeVMHo@public.gmane.org>
2012-09-26 14:35               ` Alex Williamson
2012-09-26 14:35                 ` Alex Williamson
     [not found]                 ` <1348670159.28860.183.camel-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2012-09-26 15:10                   ` Roedel, Joerg [this message]
2012-09-26 15:10                     ` Roedel, Joerg
     [not found]                     ` <20120926151044.GE10549-5C7GfCeVMHo@public.gmane.org>
2012-09-26 16:21                       ` Alex Williamson
2012-09-26 16:21                         ` Alex Williamson
     [not found]                         ` <1348676470.28860.197.camel-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2012-09-26 19:50                           ` Alex Williamson
2012-09-26 19:50                             ` Alex Williamson
     [not found]                             ` <1348689013.28860.220.camel-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2012-09-26 22:04                               ` Alex Williamson
2012-09-26 22:04                                 ` Alex Williamson
     [not found]                                 ` <1348697043.28860.235.camel-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2012-09-27 16:22                                   ` Florian Dazinger
2012-09-27 16:22                                     ` Florian Dazinger
2012-09-28 13:58                                   ` Roedel, Joerg
2012-09-28 13:58                                     ` 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=20120926151044.GE10549@amd.com \
    --to=joerg.roedel-5c7gfcevmho@public.gmane.org \
    --cc=alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=florian-Q0TRQrZM+Zzk1uMJSBkQmQ@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@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.