All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Wang2 <wei.wang2@amd.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] AMD IOMMU: Use global interrupt remapping table by default
Date: Wed, 20 Jul 2011 11:52:41 +0200	[thread overview]
Message-ID: <201107201152.41482.wei.wang2@amd.com> (raw)
In-Reply-To: <CAFLBxZa=DvN-PQP_4Q+e5A8BGe13NrN3c+M-ycpaA+M+ikz1Tw@mail.gmail.com>

On Tuesday 19 July 2011 16:14:31 George Dunlap wrote:
> Wei,
>
> Can you be more specific about which BIOSes behave poorly with
> per-device intremap tables, and why?
We found that, in some case, SATA device uses different device ids for dma 
remapping and interrupt remapping. Some early BIOSes cannot handle this 
situation correctly, so if SATA uses device id for DMA to lookup device table 
entry for intremap table and if intremap table is per-device configured, SATA 
device won't get the right table.

> The problem with a global intremap table is that, AFAICT, it's not
> fundamentally compatible with per-cpu IDTs.  With per-cpu IDTs,
> different devices may end up with interrupts mapped to different cpus
> but the same vector (i.e., device A mapped to cpu 9 vector 67, cpu B
> mapped to cpu 12 vector 67).  This is by design; the whole point of
> the per-cpu IDTs is to avoid restricting the number of IRQs to the
> number of vectors.   But it seems that the intremap table only maps
> vectors, not destination IDs; so in the example above, both devices'
> interrupts would end up being remapped to the same place, causing one
> device driver to get both sets of interrupts, and the other to get
> none.

Yes, obviously a problem...Using shared intremap table, devices uses the same 
vector and delivery mode will end up to the same remapping entry. Is per-cpu 
IDTs enable by default in Xen?

> Do I understand correctly?  If so, it seems like we should switch to
> per-device intremap tables by default; and if we're using a global
> intremap table, we need to somehow make sure that vectors are not
> shared across cpus.
I agree to use per-device table by default, since BIOS issue has been fixed 
and per-device table also has some security advantages.

Thanks,
Wei

>  -George
>
> On Wed, Oct 28, 2009 at 4:32 PM, Wei Wang2 <wei.wang2@amd.com> wrote:
> > Using a global interrupt remapping table shared by all devices has better
> > compatibility with certain old BIOSes. Per-device interrupt remapping
> > table can still be enabled by using a new parameter
> > "amd-iommu-perdev-intremap". Thanks,
> > Wei
> >
> > Signed-off-by: Wei Wang <wei.wang2@amd.com>
> > --
> > AMD GmbH, Germany
> > Operating System Research Center
> >
> > Legal Information:
> > Advanced Micro Devices GmbH
> > Karl-Hammerschmidt-Str. 34
> > 85609 Dornach b. München
> >
> > Geschäftsführer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni
> > Sitz: Dornach, Gemeinde Aschheim, Landkreis München
> > Registergericht München, HRB Nr. 43632
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

  reply	other threads:[~2011-07-20  9:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-28 16:32 [PATCH] AMD IOMMU: Use global interrupt remapping table by default Wei Wang2
2011-07-19 14:14 ` George Dunlap
2011-07-20  9:52   ` Wei Wang2 [this message]
2011-07-20 10:50     ` Ian Campbell
2011-07-20 12:34       ` Wei Wang2
2011-07-20 13:01         ` Ian Campbell
2011-07-20 15:56           ` Wei Wang2
2011-07-21  9:07             ` George Dunlap
2011-07-21 10:38               ` Wei Wang2
2011-07-21 14:36                 ` George Dunlap

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=201107201152.41482.wei.wang2@amd.com \
    --to=wei.wang2@amd.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=xen-devel@lists.xensource.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.