From: Alex Williamson <alex.williamson@redhat.com>
To: Knut Omang <knut.omang@oracle.com>
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Jan Kiszka" <jan.kiszka@siemens.com>,
"Alexander Graf" <agraf@suse.de>,
qemu-devel@nongnu.org, "Andreas Färber" <andreas.faerber@web.de>,
qemu-ppc@nongnu.org, "Le Tan" <tamlokveer@gmail.com>,
marcel@redhat.com, "Paolo Bonzini" <pbonzini@redhat.com>,
"David Gibson" <david@gibson.dropbear.id.au>,
"Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v2 0/2] intel_iommu: Add support for translation for devices behind bridges
Date: Wed, 02 Sep 2015 10:12:25 -0600 [thread overview]
Message-ID: <1441210345.20355.295.camel@redhat.com> (raw)
In-Reply-To: <1441199414.25731.115.camel@oracle.com>
On Wed, 2015-09-02 at 15:10 +0200, Knut Omang wrote:
> On Wed, 2015-09-02 at 15:30 +0300, Marcel Apfelbaum wrote:
> > On 09/01/2015 09:48 PM, Knut Omang wrote:
> > > This patch set changes the data structure used to handle address
> > > spaces within
> > > the emulated Intel iommu to support traversal also if bus numbers
> > > are dynamically
> > > allocated, as is the case for devices that sit behind root ports or
> > > downstream switches.
> > > This means that we cannot use bus number as index, instead a QLIST
> > > is used.
> > >
> > > This requires a change in the API for setup of IOMMUs which is
> > > taken care of by
> > > the first patch. The second patch implements the fix.
> > >
> > > The initial patch set had some discussion related to whether this
> > > fix, applied to the
> > > bridge code, was applicable to all bridges. No clear conclusion
> > > arised as far as I understood,
> > > in the meantime a number of people have run into the same issue as
> > > I did which lead me
> > > to implement this, so I gather it might be a useful intermediate
> > > solution that works until
> > > a better approach can be found? I believe the IOMMU emulation code
> > > has limited usefulness
> > > if it only supports devices sitting directly on the root complex.
> > Hi,
> >
> > Thank you for (re)sending the patches!
> >
> > While I believe you are perfectly right and IOMMU
> > would benefit from this addition, I saw that are some reviews
> > in the prev thread that are not purely theoretical/philosophical.
> > E.g. PCIDevice *dev field in VTDAddressSpace and maybe a few more.
>
> Yes, in principle I agree, but the problem is that there is no other
> good reference that would uniquely identify the device as the requester
> IDs (devfn) cannot be used since it changes during enumeration,
> as argued better for here:
>
> http://article.gmane.org/gmane.comp.emulators.qemu/317201
There are very specific rules for translating requester IDs across
bridges. Bus numbers can change during enumeration, devfn cannot.
devfn can however be masked by topology changes from PCIe to PCI. If we
pretend that the IOMMU can distinguish requester IDs where it can't on
real hardware, we're going to break the guest. Thanks,
Alex
> > I would suggest to address them so it will be easier to continue the
> > review process.
>
> Knut
>
> > Thank you,
> > Marcel
> >
> > >
> > > This is the thread following the initial patch set:
> > >
> > > http://thread.gmane.org/gmane.comp.emulators.qemu/302246
> > >
> > > The patch set was also discussed in this thread:
> > >
> > > http://thread.gmane.org/gmane.comp.emulators.qemu/316949
> > >
> > > Changes from v1:
> > > - Rebased to current master
> > > - Fixed minor syntax issues
> > >
> > > Knut Omang (2):
> > > iommu: Replace bus+devfn arguments with PCIDevice* in
> > > PCIIOMMUFunc
> > > intel_iommu: Add support for translation for devices behind
> > > bridges.
> > >
> > > hw/alpha/typhoon.c | 2 +-
> > > hw/i386/intel_iommu.c | 56 +++++++++++++++++++-----------
> > > -------------
> > > hw/pci-host/apb.c | 2 +-
> > > hw/pci-host/prep.c | 3 +--
> > > hw/pci-host/q35.c | 42 +++++++++++++-----------------
> > > --
> > > hw/pci/pci.c | 7 +++---
> > > hw/pci/pci_bridge.c | 6 +++++
> > > hw/ppc/spapr_pci.c | 2 +-
> > > include/hw/i386/intel_iommu.h | 6 +++--
> > > include/hw/pci/pci.h | 5 +++-
> > > 10 files changed, 62 insertions(+), 69 deletions(-)
> > >
> > > --
> > > 2.4.3
> > >
> >
next prev parent reply other threads:[~2015-09-02 16:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-01 18:48 [Qemu-devel] [PATCH v2 0/2] intel_iommu: Add support for translation for devices behind bridges Knut Omang
2015-09-01 18:48 ` [Qemu-devel] [PATCH v2 1/2] iommu: Replace bus+devfn arguments with PCIDevice* in PCIIOMMUFunc Knut Omang
2015-09-01 18:48 ` [Qemu-devel] [PATCH v2 2/2] intel_iommu: Add support for translation for devices behind bridges Knut Omang
2015-09-02 12:30 ` [Qemu-devel] [PATCH v2 0/2] " Marcel Apfelbaum
2015-09-02 13:10 ` Knut Omang
2015-09-02 16:12 ` Alex Williamson [this message]
2015-09-02 22:33 ` Benjamin Herrenschmidt
2015-09-03 5:26 ` Knut Omang
2015-09-12 18:37 ` Knut Omang
2015-09-12 23:12 ` Benjamin Herrenschmidt
2015-09-13 7:04 ` Knut Omang
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=1441210345.20355.295.camel@redhat.com \
--to=alex.williamson@redhat.com \
--cc=agraf@suse.de \
--cc=andreas.faerber@web.de \
--cc=david@gibson.dropbear.id.au \
--cc=ehabkost@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=knut.omang@oracle.com \
--cc=marcel@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=rth@twiddle.net \
--cc=tamlokveer@gmail.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).