2009-03-20 02:31:16

by Jesse Barnes

[permalink] [raw]
Subject: Re: [PATCH v3 0/6] ATS capability support for Intel IOMMU

On Thu, 12 Feb 2009 20:50:32 +0800
Yu Zhao <[email protected]> wrote:

> This patch series implements Address Translation Service support for
> the Intel IOMMU. ATS makes the PCI Endpoint be able to request the
> DMA address translation from the IOMMU and cache the translation in
> the Endpoint, thus alleviate IOMMU pressure and improve the hardware
> performance in the I/O virtualization environment.
>
>
> Changelog: v2 -> v3
> 1, throw error message if VT-d hardware detects invalid descriptor
> on Queued Invalidation interface (David Woodhouse)
> 2, avoid using pci_find_ext_capability every time when reading ATS
> Invalidate Queue Depth (Matthew Wilcox)
> Changelog: v1 -> v2
> added 'static' prefix to a local LIST_HEAD (Andrew Morton)
>
>
> Yu Zhao (6):
> PCI: support the ATS capability
> VT-d: parse ATSR in DMA Remapping Reporting Structure
> VT-d: add queue invalidation fault status support
> VT-d: add device IOTLB invalidation support
> VT-d: cleanup iommu_flush_iotlb_psi and flush_unmaps
> VT-d: support the device IOTLB

Um nevermind, this should go through the IOMMU tree (David?).

--
Jesse Barnes, Intel Open Source Technology Center


2009-03-20 02:47:34

by Zhao, Yu

[permalink] [raw]
Subject: Re: [PATCH v3 0/6] ATS capability support for Intel IOMMU

Jesse Barnes wrote:
> On Thu, 12 Feb 2009 20:50:32 +0800
> Yu Zhao <[email protected]> wrote:
>
>> This patch series implements Address Translation Service support for
>> the Intel IOMMU. ATS makes the PCI Endpoint be able to request the
>> DMA address translation from the IOMMU and cache the translation in
>> the Endpoint, thus alleviate IOMMU pressure and improve the hardware
>> performance in the I/O virtualization environment.
>>
>>
>> Changelog: v2 -> v3
>> 1, throw error message if VT-d hardware detects invalid descriptor
>> on Queued Invalidation interface (David Woodhouse)
>> 2, avoid using pci_find_ext_capability every time when reading ATS
>> Invalidate Queue Depth (Matthew Wilcox)
>> Changelog: v1 -> v2
>> added 'static' prefix to a local LIST_HEAD (Andrew Morton)
>>
>>
>> Yu Zhao (6):
>> PCI: support the ATS capability
>> VT-d: parse ATSR in DMA Remapping Reporting Structure
>> VT-d: add queue invalidation fault status support
>> VT-d: add device IOTLB invalidation support
>> VT-d: cleanup iommu_flush_iotlb_psi and flush_unmaps
>> VT-d: support the device IOTLB
>
> Um nevermind, this should go through the IOMMU tree (David?).

If it's possible, I'd like it go through the PCI tree because the ATS
depends on the SR-IOV. This dependency is not reflected in this v3
series since the SR-IOV is not in-tree and I don't want to break the
build after people apply the ATS on their tree.

So Dave, can I get an ack from you and let Jesse pull the IOMMU change
to his tree? Or let this ATS go to 2.6.31?

Thanks,
Yu

2009-03-20 11:16:35

by David Woodhouse

[permalink] [raw]
Subject: Re: [PATCH v3 0/6] ATS capability support for Intel IOMMU

On Fri, 2009-03-20 at 10:47 +0800, Zhao, Yu wrote:
> If it's possible, I'd like it go through the PCI tree because the ATS
> depends on the SR-IOV. This dependency is not reflected in this v3
> series since the SR-IOV is not in-tree and I don't want to break the
> build after people apply the ATS on their tree.

In what way will it depend on SR-IOV?

> So Dave, can I get an ack from you and let Jesse pull the IOMMU change
> to his tree? Or let this ATS go to 2.6.31?

Want to show the latest version of the patches which depend on SR-IOV,
and I can ack them?

--
David Woodhouse Open Source Technology Centre
[email protected] Intel Corporation

2009-03-23 05:21:41

by Zhao, Yu

[permalink] [raw]
Subject: Re: [PATCH v3 0/6] ATS capability support for Intel IOMMU

On Fri, Mar 20, 2009 at 07:15:51PM +0800, David Woodhouse wrote:
> On Fri, 2009-03-20 at 10:47 +0800, Zhao, Yu wrote:
> > If it's possible, I'd like it go through the PCI tree because the ATS
> > depends on the SR-IOV. This dependency is not reflected in this v3
> > series since the SR-IOV is not in-tree and I don't want to break the
> > build after people apply the ATS on their tree.
>
> In what way will it depend on SR-IOV?

The SR-IOV spec section 3.7.4 says that the Smallest Translation Unit and
the Invalidate Queue Depth fields in the Virtual Function's ATS capability
are hard-wired to 0. So we need some special handling when enabling the ATS
capability for the Virtual Function.

Table 3-26: ATS Capability Register
-------------+-----------------------------------------+---------------+--------------
Bit Location | PF and VF Register Differences From ATS | PF Attributes | VF Attributes
-------------+-----------------------------------------+---------------+--------------
| Smallest Translation Unit (STU) | |
20:16 | Hardwired to 0 for VFs. | ATS | RO
| PF value applies to all VFs. | |
-------------+-----------------------------------------+---------------+--------------
| Invalidate Queue Depth | |
28:24 | Hardwired to 0 for VFs. | ATS | RO
| Depth of shared PF input queue. | |
-------------+-----------------------------------------+---------------+--------------

> > So Dave, can I get an ack from you and let Jesse pull the IOMMU change
> > to his tree? Or let this ATS go to 2.6.31?
>
> Want to show the latest version of the patches which depend on SR-IOV,
> and I can ack them?

Sure, thanks!