All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
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 15:30:26 +0200	[thread overview]
Message-ID: <5190EAF2.6020606@redhat.com> (raw)
In-Reply-To: <20130513131348.GD14944@truffula.fritz.box>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 13/05/2013 15:13, David Gibson ha scritto:
> 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.

Suppose you have a host bridge pci_bus0 and a PCIE->PCIE bridge
pci_bus1.  pci_bus1 does not define a IOMMU callback, pci_bus0 does.

Would it work to use the PCIBus callback provided by pci_bus0, but
invoke it as

    pci_bus0->iommu_fn(pci_bus1, pci_bus0->iommu_opaque, devfn)

?

Paolo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRkOryAAoJEBvWZb6bTYbydNoQAIbBuyYTm0MvERXOFb7YkTQC
oe0B09CN2fdnWIeacl7taa1/5Pe0hY7JpuLSQCD1/4P4ovKPOROJ652BxSdDmBtG
cZTmqG35ScfhM8ES66voKMO/o7LhPiJ3OLoUUNaVvEMmXCq4ag6LQd42RMyQVGtu
hyjA5thPRV7u7/m0+iPxALxegvicxqQk/IkN5nRtXeO0LK78o5TxXX/3qMU1k7Rh
FqfxbfSA0ceFu5PUtm5TnpwArVYJUZJfJZuMpr+B8Ub5zoo0nt6nfBZG7P5Sk7Aw
MN54CfvJ/3roAS4BwFNBYbYV6ZxW6P99yUnlMcsrmUXhjsGfVxiCz7pqhTUuFnyQ
O620UTSH3rIrdEFalfrG1mZSvf550b4cc1PW/+TAd2d2uBzEq2wb/vOW9vr6/EXB
/Y7nLLHeik12sWg1bNklhnr4UYQ9FBzAo6duWCgw42OIggKSuOzRWxU4vFpX/abb
BVX/61zSTujh6qfnQdWOKQuvYlcZUI+sqHF3SUdYH7yaE+gH0PJea3vqg3H2jQgT
ktVjNuxQE2P+lL8C+VfHGoTRjZ0OgAgAo19qrCzdwX6kJocKU5apqZJ/qOvHatKq
ZoOyfnwO/HUJ6wfP1INLvgNvOIbHyQ98fIVgFtmOQbES/NRVpf0y1K+opKkJ+BXZ
kmJHRiIUcH0VnLYTmaVr
=2jMC
-----END PGP SIGNATURE-----

  reply	other threads:[~2013-05-13 13:30 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
2013-05-13 13:30     ` Paolo Bonzini [this message]
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=5190EAF2.6020606@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=mst@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 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.