[PATCH 0/2]Add Variable Page Size and IA64 Support in Intel IOMMU

[PATCH 0/2]Add Variable Page Size and IA64 Support in Intel IOMMU

[Fenghua Yu]

The following two patches (Intel IOMMU generic patch and ia64 specific patch) together enable Intel IOMMU on IA64 platform. They are applied cleanly on the latest linux-next tree which contains Intel IOMMU interrupt remapping and VT-d driver KVM support code.

If applying only the generic patch on x86-64 kernel, x86-64 IOMMU is working fine, i.e. the generic patch doesn't have compilation and functionality impact on x86-64 IOMMU. If applying only the ia64 specific patch on ia64 kernel, ia64 is working as non-IOMMU/swiotlb case. If applying both of the patches and set CONFIG_DMAR=y, ia64 IOMMU is working.

Thanks.

-Fenghua

Re: [PATCH 0/2]Add Variable Page Size and IA64 Support in Intel IOMMU

[Bjorn Helgaas]

On Wednesday 01 October 2008 10:56:06 am Fenghua Yu wrote:
> The following two patches (Intel IOMMU generic patch and ia64 specific patch) together enable Intel IOMMU on IA64 platform. They are applied cleanly on the latest linux-next tree which contains Intel IOMMU interrupt remapping and VT-d driver KVM support code.

General comment (not ia64-related): it looks like you detect the
IOMMU using the static DMAR table.  Does the IOMMU also appear in
PCI config space or the ACPI namespace?  I expect it would, because
the fact that the DMAR table is static precludes any sort of hot-plug
to add or remove IOMMUs.

If it *is* in config space or the namespace, it would be good to
exercise that discovery path to help shake out firmware bugs.  For
example, arch/ia64/hp/common/sba_iommu.c uses acpi_bus_register_driver()
to discover HP IOMMUs.  I wouldn't hold the sba_iommu.c discovery code
(most of which I take the blame for) up as a shining example of how to
do things, but it shows the point.

Bjorn

RE: [PATCH 0/2]Add Variable Page Size and IA64 Support in Intel IOMMU

[Yu, Fenghua]

>> The following two patches (Intel IOMMU generic patch and ia64 specific

>the fact that the DMAR table is static precludes any sort of hot-plug
>to add or remove IOMMUs.

The latest VT-d spec v1.1 does not support hot plug. If the feature is available in newer spec, we will support it.

Thanks.

-Fenghua

[PATCH V2 0/2] Add Variable Page Size and IA64 Support in Intel IOMMU

[Fenghua Yu]

The patche set (Intel IOMMU generic patch and ia64 specific patch) together enable Intel IOMMU on IA64 platform. They are applied cleanly on the latest linux-next tree which contains Intel IOMMU interrupt remapping and VT-d driver KVM support code.
 
If applying only the generic patch on x86-64 kernel, x86-64 IOMMU is working fine, i.e. the generic patch doesn't have compilation and functionality impact on x86-64 IOMMU. If applying only the ia64 specific patch on ia64 kernel, ia64 is working as non-IOMMU/swiotlb case. If applying both of the patches and set CONFIG_DMAR=y, ia64 IOMMU is working.
 
Thanks.
 
-Fenghua

[PATCH]iwlan dma mapping read and write changes

[Fenghua Yu]

When iwlan runs on IOMMU, IOMMU generates a lot of PTE write faults because PTE
write bit is not set on some of PTE's. This is because iwlan driver calls DMA
mapping with PCI_DMA_TODEVICE which is read only in mapping PTE. But iwlan device
actually writes to the mapped page to update its contents. This issue is not
exposed in swiotlb. But VT-d hardware can capture this fault and stop the fault
transaction.

The following patch fixes the issue.

Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>

---

 iwl-tx.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/net/wireless/iwlwifi/iwl-tx.c.orig	2009-02-10 21:28:45.000000000 -0800
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c	2009-02-10 21:41:02.000000000 -0800
@@ -148,7 +148,7 @@ static void iwl_hw_txq_free_tfd(struct i
 		pci_unmap_single(dev,
 				pci_unmap_addr(&txq->cmd[index]->meta, mapping),
 				pci_unmap_len(&txq->cmd[index]->meta, len),
-				PCI_DMA_TODEVICE);
+				PCI_DMA_BIDIRECTIONAL);
 
 	/* Unmap chunks, if any. */
 	for (i = 1; i < num_tbs; i++) {
@@ -964,7 +964,7 @@ int iwl_tx_skb(struct iwl_priv *priv, st
 	 * within command buffer array. */
 	txcmd_phys = pci_map_single(priv->pci_dev,
 				    out_cmd, sizeof(struct iwl_cmd),
-				    PCI_DMA_TODEVICE);
+				    PCI_DMA_BIDIRECTIONAL);
 	pci_unmap_addr_set(&out_cmd->meta, mapping, txcmd_phys);
 	pci_unmap_len_set(&out_cmd->meta, len, sizeof(struct iwl_cmd));
 	/* Add buffer containing Tx command and MAC(!) header to TFD's
@@ -1115,7 +1115,7 @@ int iwl_enqueue_hcmd(struct iwl_priv *pr
 			IWL_MAX_SCAN_SIZE : sizeof(struct iwl_cmd);
 
 	phys_addr = pci_map_single(priv->pci_dev, out_cmd,
-				   len, PCI_DMA_TODEVICE);
+				   len, PCI_DMA_BIDIRECTIONAL);
 	pci_unmap_addr_set(&out_cmd->meta, mapping, phys_addr);
 	pci_unmap_len_set(&out_cmd->meta, len, len);
 	phys_addr += offsetof(struct iwl_cmd, hdr);
@@ -1212,7 +1212,7 @@ static void iwl_hcmd_queue_reclaim(struc
 	pci_unmap_single(priv->pci_dev,
 		pci_unmap_addr(&txq->cmd[cmd_idx]->meta, mapping),
 		pci_unmap_len(&txq->cmd[cmd_idx]->meta, len),
-		PCI_DMA_TODEVICE);
+		PCI_DMA_BIDIRECTIONAL);
 
 	for (idx = iwl_queue_inc_wrap(idx, q->n_bd); q->read_ptr != idx;
 	     q->read_ptr = iwl_queue_inc_wrap(q->read_ptr, q->n_bd)) {

RE: [PATCH]iwlan dma mapping read and write changes

[Bhavesh Davda]

Looks good to me. Ship it!

- Bhavesh
 
Bhavesh P. Davda

> -----Original Message-----
> From: iommu-bounces@lists.linux-foundation.org [mailto:iommu-
> bounces@lists.linux-foundation.org] On Behalf Of Fenghua Yu
> Sent: Wednesday, February 11, 2009 10:27 AM
> To: David Woodhouse; Ingo Molnar; Stephen Rothwell; Andrew Morton;
> Johannes Berg; Emmanuel Grumbach; Tomas Winkler; Zhu Yi; Chris Wright
> Cc: iommu@lists.linux-foundation.org; LKML
> Subject: [PATCH]iwlan dma mapping read and write changes
> 
> When iwlan runs on IOMMU, IOMMU generates a lot of PTE write faults
> because PTE
> write bit is not set on some of PTE's. This is because iwlan driver
> calls DMA
> mapping with PCI_DMA_TODEVICE which is read only in mapping PTE. But
> iwlan device
> actually writes to the mapped page to update its contents. This issue
> is not
> exposed in swiotlb. But VT-d hardware can capture this fault and stop
> the fault
> transaction.
> 
> The following patch fixes the issue.
> 
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> 
> ---
> 
>  iwl-tx.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> --- a/drivers/net/wireless/iwlwifi/iwl-tx.c.orig	2009-02-10
> 21:28:45.000000000 -0800
> +++ b/drivers/net/wireless/iwlwifi/iwl-tx.c	2009-02-10
> 21:41:02.000000000 -0800
> @@ -148,7 +148,7 @@ static void iwl_hw_txq_free_tfd(struct i
>  		pci_unmap_single(dev,
>  				pci_unmap_addr(&txq->cmd[index]->meta,
> mapping),
>  				pci_unmap_len(&txq->cmd[index]->meta, len),
> -				PCI_DMA_TODEVICE);
> +				PCI_DMA_BIDIRECTIONAL);
> 
>  	/* Unmap chunks, if any. */
>  	for (i = 1; i < num_tbs; i++) {
> @@ -964,7 +964,7 @@ int iwl_tx_skb(struct iwl_priv *priv, st
>  	 * within command buffer array. */
>  	txcmd_phys = pci_map_single(priv->pci_dev,
>  				    out_cmd, sizeof(struct iwl_cmd),
> -				    PCI_DMA_TODEVICE);
> +				    PCI_DMA_BIDIRECTIONAL);
>  	pci_unmap_addr_set(&out_cmd->meta, mapping, txcmd_phys);
>  	pci_unmap_len_set(&out_cmd->meta, len, sizeof(struct iwl_cmd));
>  	/* Add buffer containing Tx command and MAC(!) header to TFD's
> @@ -1115,7 +1115,7 @@ int iwl_enqueue_hcmd(struct iwl_priv *pr
>  			IWL_MAX_SCAN_SIZE : sizeof(struct iwl_cmd);
> 
>  	phys_addr = pci_map_single(priv->pci_dev, out_cmd,
> -				   len, PCI_DMA_TODEVICE);
> +				   len, PCI_DMA_BIDIRECTIONAL);
>  	pci_unmap_addr_set(&out_cmd->meta, mapping, phys_addr);
>  	pci_unmap_len_set(&out_cmd->meta, len, len);
>  	phys_addr += offsetof(struct iwl_cmd, hdr);
> @@ -1212,7 +1212,7 @@ static void iwl_hcmd_queue_reclaim(struc
>  	pci_unmap_single(priv->pci_dev,
>  		pci_unmap_addr(&txq->cmd[cmd_idx]->meta, mapping),
>  		pci_unmap_len(&txq->cmd[cmd_idx]->meta, len),
> -		PCI_DMA_TODEVICE);
> +		PCI_DMA_BIDIRECTIONAL);
> 
>  	for (idx = iwl_queue_inc_wrap(idx, q->n_bd); q->read_ptr != idx;
>  	     q->read_ptr = iwl_queue_inc_wrap(q->read_ptr, q->n_bd)) {
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/iommu

RE: [PATCH]iwlan dma mapping read and write changes

[Yu, Fenghua]

>Looks good to me. Ship it!
>
>- Bhavesh
> 
>Bhavesh P. Davda

Reviewed-by: Bhavesh Davda <bhavesh@vmware.com>

Thanks.

-Fenghua

Re: [PATCH]iwlan dma mapping read and write changes

[Chris Wright]

* Fenghua Yu (fenghua.yu@intel.com) wrote:
> When iwlan runs on IOMMU, IOMMU generates a lot of PTE write faults because PTE
> write bit is not set on some of PTE's. This is because iwlan driver calls DMA
> mapping with PCI_DMA_TODEVICE which is read only in mapping PTE. But iwlan device
> actually writes to the mapped page to update its contents. This issue is not
> exposed in swiotlb. But VT-d hardware can capture this fault and stop the fault
> transaction.
> 
> The following patch fixes the issue.

Yes, plain old driver bug!  This fixes the iwlagn vt-d issue.


> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>

Tested-by: Chris Wright <chrisw@sous-sol.org>

thanks,
chris

RE: [PATCH]iwlan dma mapping read and write changes

[Winkler, Tomas]

>-----Original Message-----
>From: Yu, Fenghua
>Sent: Wednesday, February 11, 2009 8:27 PM
>To: David Woodhouse; Ingo Molnar; Stephen Rothwell; Andrew Morton; Johannes
>Berg; Grumbach, Emmanuel; Winkler, Tomas; Zhu, Yi; Chris Wright
>Cc: LKML; iommu@lists.linux-foundation.org
>Subject: [PATCH]iwlan dma mapping read and write changes
>
>When iwlan runs on IOMMU, IOMMU generates a lot of PTE write faults because
>PTE
>write bit is not set on some of PTE's. This is because iwlan driver calls
>DMA
>mapping with PCI_DMA_TODEVICE which is read only in mapping PTE. But iwlan
>device
>actually writes to the mapped page to update its contents. This issue is
>not
>exposed in swiotlb. But VT-d hardware can capture this fault and stop the
>fault
>transaction.
>
>The following patch fixes the issue.
>
>Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>

Indeed the firmware/ucode write back to host memory to update retry counter for APMDU packets. I'm not sure if this is needed for legacy traffic, though.   

>---
>
> iwl-tx.c |    8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
>--- a/drivers/net/wireless/iwlwifi/iwl-tx.c.orig	2009-02-10
>21:28:45.000000000 -0800
>+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c	2009-02-10
>21:41:02.000000000 -0800
>@@ -148,7 +148,7 @@ static void iwl_hw_txq_free_tfd(struct i
> 		pci_unmap_single(dev,
> 				pci_unmap_addr(&txq->cmd[index]->meta, mapping),
> 				pci_unmap_len(&txq->cmd[index]->meta, len),
>-				PCI_DMA_TODEVICE);
>+				PCI_DMA_BIDIRECTIONAL);
>
> 	/* Unmap chunks, if any. */
> 	for (i = 1; i < num_tbs; i++) {
>@@ -964,7 +964,7 @@ int iwl_tx_skb(struct iwl_priv *priv, st
> 	 * within command buffer array. */
> 	txcmd_phys = pci_map_single(priv->pci_dev,
> 				    out_cmd, sizeof(struct iwl_cmd),
>-				    PCI_DMA_TODEVICE);
>+				    PCI_DMA_BIDIRECTIONAL);
> 	pci_unmap_addr_set(&out_cmd->meta, mapping, txcmd_phys);
> 	pci_unmap_len_set(&out_cmd->meta, len, sizeof(struct iwl_cmd));
> 	/* Add buffer containing Tx command and MAC(!) header to TFD's
>@@ -1115,7 +1115,7 @@ int iwl_enqueue_hcmd(struct iwl_priv *pr
> 			IWL_MAX_SCAN_SIZE : sizeof(struct iwl_cmd);
>
> 	phys_addr = pci_map_single(priv->pci_dev, out_cmd,
>-				   len, PCI_DMA_TODEVICE);
>+				   len, PCI_DMA_BIDIRECTIONAL);
> 	pci_unmap_addr_set(&out_cmd->meta, mapping, phys_addr);
> 	pci_unmap_len_set(&out_cmd->meta, len, len);
> 	phys_addr += offsetof(struct iwl_cmd, hdr);
>@@ -1212,7 +1212,7 @@ static void iwl_hcmd_queue_reclaim(struc
> 	pci_unmap_single(priv->pci_dev,
> 		pci_unmap_addr(&txq->cmd[cmd_idx]->meta, mapping),
> 		pci_unmap_len(&txq->cmd[cmd_idx]->meta, len),
>-		PCI_DMA_TODEVICE);
>+		PCI_DMA_BIDIRECTIONAL);
>
> 	for (idx = iwl_queue_inc_wrap(idx, q->n_bd); q->read_ptr != idx;
> 	     q->read_ptr = iwl_queue_inc_wrap(q->read_ptr, q->n_bd)) {
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

RE: [PATCH]iwlan dma mapping read and write changes

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

On Wed, 2009-02-11 at 23:27 +0200, Winkler, Tomas wrote:

> >mapping with PCI_DMA_TODEVICE which is read only in mapping PTE. But iwlan
> >device
> >actually writes to the mapped page to update its contents. This issue is
> >not
> >exposed in swiotlb. But VT-d hardware can capture this fault and stop the
> >fault
> >transaction.
> >
> >The following patch fixes the issue.
> >
> >Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> Acked-by: Tomas Winkler <tomas.winkler@intel.com>
> 
> Indeed the firmware/ucode write back to host memory to update retry
> counter for APMDU packets. I'm not sure if this is needed for legacy
> traffic, though.   

I don't think they can be seeing AMPDU packets since that is, well,
broken?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: [PATCH]iwlan dma mapping read and write changes

[Winkler, Tomas]

>-----Original Message-----
>From: Johannes Berg [mailto:johannes@sipsolutions.net]
>Sent: Wednesday, February 11, 2009 11:34 PM
>To: Winkler, Tomas
>Cc: Yu, Fenghua; David Woodhouse; Ingo Molnar; Stephen Rothwell; Andrew
>Morton; Grumbach, Emmanuel; Zhu, Yi; Chris Wright; LKML; iommu@lists.linux-
>foundation.org
>Subject: RE: [PATCH]iwlan dma mapping read and write changes
>
>On Wed, 2009-02-11 at 23:27 +0200, Winkler, Tomas wrote:
>
>> >mapping with PCI_DMA_TODEVICE which is read only in mapping PTE. But
>iwlan
>> >device
>> >actually writes to the mapped page to update its contents. This issue is
>> >not
>> >exposed in swiotlb. But VT-d hardware can capture this fault and stop
>the
>> >fault
>> >transaction.
>> >
>> >The following patch fixes the issue.
>> >
>> >Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
>> Acked-by: Tomas Winkler <tomas.winkler@intel.com>
>>
>> Indeed the firmware/ucode write back to host memory to update retry
>> counter for APMDU packets. I'm not sure if this is needed for legacy
>> traffic, though.
>
>I don't think they can be seeing AMPDU packets since that is, well,
>broken?

Currently I'm not aware of any other cases where memory is accessed back but I may have not complete info.  Will be back with the answer tomorrow.
Tomas 

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

RE: [PATCH]iwlan dma mapping read and write changes

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]


> >> Indeed the firmware/ucode write back to host memory to update retry
> >> counter for APMDU packets. I'm not sure if this is needed for legacy
> >> traffic, though.
> >
> >I don't think they can be seeing AMPDU packets since that is, well,
> >broken?
> 
> Currently I'm not aware of any other cases where memory is accessed
> back but I may have not complete info.  Will be back with the answer
> tomorrow.

I don't think it really matters, since AMPDU packets will be fixed soon,
and for those you know it's necessary (and the report says that under
some other circumstances it's also necessary). Unless there'd be some
benefit from using BIDI only when we know it'll be needed, and using
TODEV in the other cases?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: [PATCH]iwlan dma mapping read and write changes

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

On Wed, 2009-02-11 at 22:47 +0100, Johannes Berg wrote:
> > >> Indeed the firmware/ucode write back to host memory to update retry
> > >> counter for APMDU packets. I'm not sure if this is needed for legacy
> > >> traffic, though.
> > >
> > >I don't think they can be seeing AMPDU packets since that is, well,
> > >broken?
> > 
> > Currently I'm not aware of any other cases where memory is accessed
> > back but I may have not complete info.  Will be back with the answer
> > tomorrow.
> 
> I don't think it really matters, since AMPDU packets will be fixed soon,
> and for those you know it's necessary (and the report says that under
> some other circumstances it's also necessary). Unless there'd be some
> benefit from using BIDI only when we know it'll be needed, and using
> TODEV in the other cases?

Or if there's a firmware bug.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: [PATCH]iwlan dma mapping read and write changes

[Winkler, Tomas]

>-----Original Message-----
>From: Johannes Berg [mailto:johannes@sipsolutions.net]
>Sent: Wednesday, February 11, 2009 11:50 PM
>To: Winkler, Tomas
>Cc: Yu, Fenghua; David Woodhouse; Ingo Molnar; Stephen Rothwell; Grumbach,
>Emmanuel; Zhu, Yi; Chris Wright; LKML; iommu@lists.linux-foundation.org
>Subject: RE: [PATCH]iwlan dma mapping read and write changes
>
>On Wed, 2009-02-11 at 22:47 +0100, Johannes Berg wrote:
>> > >> Indeed the firmware/ucode write back to host memory to update retry
>> > >> counter for APMDU packets. I'm not sure if this is needed for legacy
>> > >> traffic, though.
>> > >
>> > >I don't think they can be seeing AMPDU packets since that is, well,
>> > >broken?
>> >
>> > Currently I'm not aware of any other cases where memory is accessed
>> > back but I may have not complete info.  Will be back with the answer
>> > tomorrow.
>>
>> I don't think it really matters, since AMPDU packets will be fixed soon,
>> and for those you know it's necessary (and the report says that under
>> some other circumstances it's also necessary). Unless there'd be some
>> benefit from using BIDI only when we know it'll be needed, and using
>> TODEV in the other cases?
>
>Or if there's a firmware bug.

That's why it's better to clear the picture. 
Fenghua
What exact HW do you get this error?

Thanks
Tomas 

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

RE: [PATCH]iwlan dma mapping read and write changes

[Yu, Fenghua]

>>> > >> Indeed the firmware/ucode write back to host memory to update retry
>>> > >> counter for APMDU packets. I'm not sure if this is needed for legacy
>>> > >> traffic, though.
>> > >
>> > >I don't think they can be seeing AMPDU packets since that is, well,
>> > >broken?
>> >
>> > Currently I'm not aware of any other cases where memory is accessed
>> > back but I may have not complete info.  Will be back with the answer
>> > tomorrow.
>>
>> I don't think it really matters, since AMPDU packets will be fixed soon,
>> and for those you know it's necessary (and the report says that under
>> some other circumstances it's also necessary). Unless there'd be some
>> benefit from using BIDI only when we know it'll be needed, and using
>> TODEV in the other cases?
>
>Or if there's a firmware bug.

>That's why it's better to clear the picture. 
>Fenghua
>What exact HW do you get this error?

This is Lenovo T400 wireless lan. Firmware version is 5.4.1.16. I think this issue happens on other platform/hw as well.

Thanks.

-Fenghua

RE: [PATCH]iwlan dma mapping read and write changes

[David Woodhouse]

On Thu, 2009-02-12 at 00:10 +0200, Winkler, Tomas wrote:
> 
> >-----Original Message-----
> >From: Johannes Berg [mailto:johannes@sipsolutions.net]
> >Sent: Wednesday, February 11, 2009 11:50 PM
> >To: Winkler, Tomas
> >Cc: Yu, Fenghua; David Woodhouse; Ingo Molnar; Stephen Rothwell; Grumbach,
> >Emmanuel; Zhu, Yi; Chris Wright; LKML; iommu@lists.linux-foundation.org
> >Subject: RE: [PATCH]iwlan dma mapping read and write changes
> >
> >On Wed, 2009-02-11 at 22:47 +0100, Johannes Berg wrote:
> >> > >> Indeed the firmware/ucode write back to host memory to update retry
> >> > >> counter for APMDU packets. I'm not sure if this is needed for legacy
> >> > >> traffic, though.
> >> > >
> >> > >I don't think they can be seeing AMPDU packets since that is, well,
> >> > >broken?
> >> >
> >> > Currently I'm not aware of any other cases where memory is accessed
> >> > back but I may have not complete info.  Will be back with the answer
> >> > tomorrow.
> >>
> >> I don't think it really matters, since AMPDU packets will be fixed soon,
> >> and for those you know it's necessary (and the report says that under
> >> some other circumstances it's also necessary). Unless there'd be some
> >> benefit from using BIDI only when we know it'll be needed, and using
> >> TODEV in the other cases?
> >
> >Or if there's a firmware bug.
> 
> That's why it's better to clear the picture. 
> Fenghua
> What exact HW do you get this error?

Lenovo T400.

00:00.0 0600: 8086:2a40 (rev 07)
00:02.0 0300: 8086:2a42 (rev 07)
00:02.1 0380: 8086:2a43 (rev 07)
00:03.0 0780: 8086:2a44 (rev 07)
00:03.2 0101: 8086:2a46 (rev 07)
00:03.3 0700: 8086:2a47 (rev 07)
00:19.0 0200: 8086:10f5 (rev 03)
00:1a.0 0c03: 8086:2937 (rev 03)
00:1a.1 0c03: 8086:2938 (rev 03)
00:1a.2 0c03: 8086:2939 (rev 03)
00:1a.7 0c03: 8086:293c (rev 03)
00:1b.0 0403: 8086:293e (rev 03)
00:1c.0 0604: 8086:2940 (rev 03)
00:1c.1 0604: 8086:2942 (rev 03)
00:1c.2 0604: 8086:2944 (rev 03)
00:1c.3 0604: 8086:2946 (rev 03)
00:1c.4 0604: 8086:2948 (rev 03)
00:1d.0 0c03: 8086:2934 (rev 03)
00:1d.1 0c03: 8086:2935 (rev 03)
00:1d.2 0c03: 8086:2936 (rev 03)
00:1d.7 0c03: 8086:293a (rev 03)
00:1e.0 0604: 8086:2448 (rev 93)
00:1f.0 0601: 8086:2917 (rev 03)
00:1f.2 0106: 8086:2929 (rev 03)
00:1f.3 0c05: 8086:2930 (rev 03)
03:00.0 0280: 8086:4236 
04:00.0 0580: 8086:444e (rev 11)
15:00.0 0607: 1180:0476 (rev ba)
15:00.1 0c00: 1180:0832 (rev 04)

-- 
dwmw2

RE: [PATCH]iwlan dma mapping read and write changes

[Winkler, Tomas]

>-----Original Message-----
>From: David Woodhouse [mailto:dwmw2@infradead.org]
>Sent: Thursday, February 12, 2009 12:14 AM
>To: Winkler, Tomas
>Cc: Johannes Berg; Yu, Fenghua; Ingo Molnar; Stephen Rothwell; Grumbach,
>Emmanuel; Zhu, Yi; Chris Wright; LKML; iommu@lists.linux-foundation.org
>Subject: RE: [PATCH]iwlan dma mapping read and write changes
>
>On Thu, 2009-02-12 at 00:10 +0200, Winkler, Tomas wrote:
>>
>> >-----Original Message-----
>> >From: Johannes Berg [mailto:johannes@sipsolutions.net]
>> >Sent: Wednesday, February 11, 2009 11:50 PM
>> >To: Winkler, Tomas
>> >Cc: Yu, Fenghua; David Woodhouse; Ingo Molnar; Stephen Rothwell;
>Grumbach,
>> >Emmanuel; Zhu, Yi; Chris Wright; LKML; iommu@lists.linux-foundation.org
>> >Subject: RE: [PATCH]iwlan dma mapping read and write changes
>> >
>> >On Wed, 2009-02-11 at 22:47 +0100, Johannes Berg wrote:
>> >> > >> Indeed the firmware/ucode write back to host memory to update
>retry
>> >> > >> counter for APMDU packets. I'm not sure if this is needed for
>legacy
>> >> > >> traffic, though.
>> >> > >
>> >> > >I don't think they can be seeing AMPDU packets since that is, well,
>> >> > >broken?
>> >> >
>> >> > Currently I'm not aware of any other cases where memory is accessed
>> >> > back but I may have not complete info.  Will be back with the answer
>> >> > tomorrow.
>> >>
>> >> I don't think it really matters, since AMPDU packets will be fixed
>soon,
>> >> and for those you know it's necessary (and the report says that under
>> >> some other circumstances it's also necessary). Unless there'd be some
>> >> benefit from using BIDI only when we know it'll be needed, and using
>> >> TODEV in the other cases?
>> >
>> >Or if there's a firmware bug.
>>
>> That's why it's better to clear the picture.
>> Fenghua
>> What exact HW do you get this error?
>
>Lenovo T400.
>


>03:00.0 0280: 8086:4236
>

I can confirm that for 5000 series the patch is required also for regular frames. In this particular machine the NIC is 5300. For 4965 only for AMPDU frames are affected also the implementation is not the same but I'm not sure if it makes any sense to differentiate. 

Does anybody know what performance implications of this change are? 

Thanks Tomas  


---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.