From: David Gibson <david@gibson.dropbear.id.au>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: aik@ozlabs.ru, alex.williamson@redhat.com, mst@redhat.com,
qemu-devel@nongnu.org, agraf@suse.de
Subject: Re: [Qemu-devel] [0/8] RFC: VFIO and guest side IOMMUs, revisited
Date: Mon, 13 May 2013 23:13:48 +1000 [thread overview]
Message-ID: <20130513131348.GD14944@truffula.fritz.box> (raw)
In-Reply-To: <5190DB42.10002@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]
On Mon, May 13, 2013 at 02:23:30PM +0200, Paolo Bonzini wrote:
> Il 13/05/2013 12:54, David Gibson ha scritto:
> > Specifically the way the iommu is
> > determined from a callback in the PCIBus means that it won't be
> > assigned for devices under a PCI-PCI bridge.
>
> Right. I saw the report from Alexey, but I am a bit wary of touching it
> because it's not a regression. In fact there is even a FIXME for it:
>
> /* FIXME: inherit memory region from bus creator */
Uh.. sort of.
> Perhaps we can make pci_iommu_as a Bus method, where the default
> implementation looks up along the chain, and the end of the recursion is
> in SysBus or in PCI buses that have set the callback.
So, this is complicated by the fact that there are two cases, and they
can both be found in existing hardware.
1) One is where devices behind the bridge are not visible /
differentiable to the IOMMU, and so effectively all their DMAs
originate from the bridge device itself. In this case the correct
thing is to give all devices under the bridge the same DMA
AddressSpace as the bridge device, as suggested by the FIXME. This
will be typical behaviour for PCI-E to PCI bridges.
2) The other case is where the bridge passes through RIDs, so that the
IOMMU can still differentiate devices behind it. For this case, we
really want the hook to be in the host bridge / root bus, and it can
make a decision based on the full bus/dev/fn information. This will
be typical for PCI-E to PCI-E bridges (or switches or nexuses or
whatever they're usually called for PCI-E). This case will be very
important as we start to model newer PCI-E based machines by default,
where typically *all* devices are behind a logical p2p bridge inside
the root complex (but are still differentiable by the Intel IOMMU
amongst others).
I'm not sure at this stage how to properly handle both cases.
--
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2013-05-13 13:14 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-13 10:54 [Qemu-devel] [0/8] RFC: VFIO and guest side IOMMUs, revisited David Gibson
2013-05-13 10:54 ` [Qemu-devel] [PATCH 1/8] iommu: Fix compile error in ioapic.c David Gibson
2013-05-13 12:14 ` Paolo Bonzini
2013-05-13 10:54 ` [Qemu-devel] [PATCH 2/8] pci: Don't del_subgregion on a non subregion David Gibson
2013-05-13 12:14 ` Paolo Bonzini
2013-05-13 10:54 ` [Qemu-devel] [PATCH 3/8] pci: Rework PCI iommu lifetime assumptions David Gibson
2013-05-13 12:15 ` Paolo Bonzini
2013-05-13 10:54 ` [Qemu-devel] [PATCH 4/8] pci: Use AddressSpace rather than MemoryRegion to represent PCI DMA space David Gibson
2013-05-13 12:16 ` Paolo Bonzini
2013-05-13 10:54 ` [Qemu-devel] [PATCH 5/8] pci: Introduce helper to retrieve a PCI device's DMA address space David Gibson
2013-05-13 10:54 ` [Qemu-devel] [PATCH 6/8] memory: Sanity check that no listeners remain on a destroyed AddressSpace David Gibson
2013-05-13 11:10 ` Peter Maydell
2013-05-13 11:48 ` David Gibson
2013-05-13 12:07 ` Peter Maydell
2013-05-13 12:19 ` Paolo Bonzini
2013-05-13 12:57 ` David Gibson
2013-05-13 10:54 ` [Qemu-devel] [PATCH 7/8] vfio: Introduce VFIO address spaces David Gibson
2013-05-13 21:32 ` Alex Williamson
2013-05-14 1:00 ` David Gibson
2013-05-13 10:54 ` [Qemu-devel] [PATCH 8/8] vfio: Create VFIOAddressSpace objects as needed David Gibson
2013-05-13 21:33 ` Alex Williamson
2013-05-14 1:58 ` David Gibson
2013-05-13 12:23 ` [Qemu-devel] [0/8] RFC: VFIO and guest side IOMMUs, revisited Paolo Bonzini
2013-05-13 13:13 ` David Gibson [this message]
2013-05-13 13:30 ` Paolo Bonzini
2013-05-14 2:39 ` David Gibson
2013-05-14 9:58 ` Paolo Bonzini
2013-05-15 3:55 ` David Gibson
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=20130513131348.GD14944@truffula.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.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 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).