From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alex Williamson <alex.williamson@redhat.com>,
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: Thu, 03 Sep 2015 08:33:30 +1000 [thread overview]
Message-ID: <1441233210.2668.90.camel@kernel.crashing.org> (raw)
In-Reply-To: <1441210345.20355.295.camel@redhat.com>
On Wed, 2015-09-02 at 10:12 -0600, Alex Williamson wrote:
> 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,
Note that whether a PCI / PCI-X bridge will mask devfn, bus# or both or
even mask it partially (number of bits) or replace some transfers with
its own RID ... depends on a given bridge implementation.
Another thing is while I agree that the bus number is problematic,
since it changes, it is still what the HW actually uses to match the
requester in practice, at least on PHB and I would think on Intel.
The problem is more fundamental. qemu is trying to bind devices to
address spaces in a fixed way at device creation time, while this is
lazily resolved in HW at the point of the DMA occurring.
One way to fix it is to effectively have an address space per device,
and have the iommu translate function figure out the binding
dynamically and flush things if it detects a change. But that is tricky
for vfio and it means invalidations will have to iterate all address
spaces.
The other option is to create Address Spaces on the fly as we lookup
domains, and bind them to devices lazily, but again, we need to deal
with changes/invalidations and that can be nasty with VFIO.
Sadly, I can't think of a silver bullet.
Cheers,
Ben.
> 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 22:34 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
2015-09-02 22:33 ` Benjamin Herrenschmidt [this message]
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=1441233210.2668.90.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=agraf@suse.de \
--cc=alex.williamson@redhat.com \
--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).