[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [0/8] RFC: VFIO and guest side IOMMUs, revisited
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [0/8] RFC: VFIO and guest side IOMMUs, revisited |
Date: |
Tue, 14 May 2013 11:58:16 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 14/05/2013 04:39, David Gibson ha scritto:
> On Mon, May 13, 2013 at 03:30:26PM +0200, Paolo Bonzini wrote:
>> -----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)
>
> Hrm. I'm a bit nervous about that, because I think when writing
> an iommu_fn it would be very easy to forget that it could be called
> with a bus other than the one the hook is attached to - and e.g.
> assuming they can use bus->qbus.parent_dev to get to the host
> bridge.
I think we can fix that by removing the opaque, and just passing in
the PCIBus.
Then it's more obvious
pci_bus0->iommu_fn(pci_bus0, pci_bus1, devfn)
and almost the same, since the host bridge is just a container_of away
from pci_bus0.
Paolo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRkgq4AAoJEBvWZb6bTYbyDeUP/RyQrKYOJAg7LX7Pj6ZyK4Dh
kH2FN7HimDG1/zWxc91wgRBOT5Q49kHlQvirSHfgvaTcEZs15rfNRrSqi0SisZGQ
2e4Dvxwv3YNIsc9hSvCa14QwZnWsQ2iQYepHMP5zQJ5FWr5OLrqEKWTwM3bsAcli
iYyDPWG4p+6knog5hIDLQ+/3TdJgRW5pLY4ZeYdDVB4azdRUpEn/OhYYT4tqrnMU
lZuinAYR/gF2vrnEc9RbDlRy+SVBn69oAfTnbsvQKkD5HAWD7NFEhIPd/HS/DoWz
KWyGBccXdgPvmRFkCmnRNnVUlvPziZNYZlS+vrTW8BiQS6C/ZZOuYyPpIzpHeAb+
t/Ds7nuQzzqj2kJIZlbhiRlEIXzLkXwcsZg8IW1Q1/wANprwYl2S6xyP9qhjUDDm
mjZOfD+miWoOmxAzK5RiWM+jhiN+EaZLLrwxjzxR6w50/T2sqa3AJxSasTsZtLLl
NaMX1bHnpcYA2XTMsMWEoReprvm5mBEcgAfzr5X2+uCd4GdI3/hfCgBkn4LCB5wp
vi8rwQZ0ULcHqV8qs2iEEGNwt7IAs/XAS/yCr3RQ9bd6cabAQyMMFIXqE5YHAU60
jh3cVQcr2TjT1+dFP/+kVnNmwHKiVcbu7EhAhg/NHGoxnKxcMRI7Iy1tQvBivEe6
Hxojhub17ah3JdB4vOOW
=Zz9q
-----END PGP SIGNATURE-----
- [Qemu-devel] [PATCH 5/8] pci: Introduce helper to retrieve a PCI device's DMA address space, (continued)
- [Qemu-devel] [PATCH 5/8] pci: Introduce helper to retrieve a PCI device's DMA address space, David Gibson, 2013/05/13
- [Qemu-devel] [PATCH 8/8] vfio: Create VFIOAddressSpace objects as needed, David Gibson, 2013/05/13
- [Qemu-devel] [PATCH 3/8] pci: Rework PCI iommu lifetime assumptions, David Gibson, 2013/05/13
- Re: [Qemu-devel] [0/8] RFC: VFIO and guest side IOMMUs, revisited, Paolo Bonzini, 2013/05/13
- Re: [Qemu-devel] [0/8] RFC: VFIO and guest side IOMMUs, revisited, David Gibson, 2013/05/13
- Re: [Qemu-devel] [0/8] RFC: VFIO and guest side IOMMUs, revisited, Paolo Bonzini, 2013/05/13
- Re: [Qemu-devel] [0/8] RFC: VFIO and guest side IOMMUs, revisited, David Gibson, 2013/05/13
- Re: [Qemu-devel] [0/8] RFC: VFIO and guest side IOMMUs, revisited,
Paolo Bonzini <=
- Re: [Qemu-devel] [0/8] RFC: VFIO and guest side IOMMUs, revisited, David Gibson, 2013/05/14