From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: clean up and modularize arch dma_mapping interface V2 Date: Sat, 24 Jun 2017 10:36:56 -0500 Message-ID: <1498318616.31581.87.camel@kernel.crashing.org> References: <20170616181059.19206-1-hch@lst.de> <162d7932-5766-4c29-5471-07d1b699190a@oracle.com> <20170624071855.GD14580@lst.de> Mime-Version: 1.0 Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20170624071855.GD14580@lst.de> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Content-Type: text/plain; charset="us-ascii" To: Christoph Hellwig , tndave Cc: linux-mips@linux-mips.org, sparclinux@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-ia64@vger.kernel.org, linux-c6x-dev@linux-c6x.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, linux-xtensa@linux-xtensa.org, x86@kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, dmaengine@vger.kernel.org, iommu@lists.linux-foundation.org, openrisc@lists.librecores.org, linux-hexagon@vger.kernel.org, linux-tegra@vger.kernel.org, xen-devel@lists.xenproject.org, linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org T24gU2F0LCAyMDE3LTA2LTI0IGF0IDA5OjE4ICswMjAwLCBDaHJpc3RvcGggSGVsbHdpZyB3cm90 ZToKPiBPbiBXZWQsIEp1biAyMSwgMjAxNyBhdCAxMjoyNDoyOFBNIC0wNzAwLCB0bmRhdmUgd3Jv dGU6Cj4gPiBUaGFua3MgZm9yIGRvaW5nIHRoaXMuCj4gPiBTbyBhcmNocyBjYW4gc3RpbGwgaGF2 ZSB0aGVpciBvd24gZGVmaW5pdGlvbiBmb3IgZG1hX3NldF9tYXNrKCkgaWYgCj4gPiBIQVZFX0FS Q0hfRE1BX1NFVF9NQVNLIGlzIHk/Cj4gPiAoYW5kIHNpbWlsYXJseSBmb3IgZG1hX3NldF9jb2hl cmVudF9tYXNrKCkgd2hlbiAKPiA+IENPTkZJR19BUkNIX0hBU19ETUFfU0VUX0NPSEVSRU5UX01B U0sgaXMgeSkKPiA+IEFueSBwbGFuIHRvIGNoYW5nZSB0aGVzZT8KPiAKPiBZZXMsIHRob3NlIHNo b3VsZCBnbyBhd2F5LCBidXQgSSdtIG5vdCBlbnRpcmVseSBzdXJlIGhvdyB5ZXQuICBXZSdsbAo+ IG5lZWQgc29tZSBob29rIGZvciBzd2l0Y2hpbmcgYmV0d2VlbiBhbiBJT01NVSBhbmQgYSBkaXJl Y3QgbWFwcGluZwo+IChJIGd1ZXNzIHRoYXQncyB3aGF0IHlvdSB3YW50IHRvIGRvIGZvciBzcGFy YyBhcyB3ZWxsPyksIGFuZCBJIG5lZWQKPiB0byBmaW5kIHRoZSBiZXN0IHdheSB0byBkbyB0aGF0 LiAgUmVpbXBsZW1lbnRpbmcgYWxsIG9mIGRtYV9zZXRfbWFzawo+IGFuZCBkbWFfc2V0X2NvaGVy ZW50X21hc2sgaXMgc29tZXRoaW5nIHRoYXQgSSB3YW50IHRvIG1vdmUgYXdheSBmcm9tLgoKSSB0 aGluayB3ZSBzdGlsbCBuZWVkIHRvIGRvIGl0LiBGb3IgZXhhbXBsZSB3ZSBoYXZlIGEgYnVuY2gg bmV3ICJmdW5reSIKY2FzZXMuCgpXZSBhbHJlYWR5IGhhdmUgdGhlIGNhc2Ugd2hlcmUgd2UgbWl4 IHRoZSBkaXJlY3QgYW5kIGlvbW11IG1hcHBpbmdzLApvbiBzb21lIHBvd2VycGMgcGxhdGZvcm1z IHRoYXQgdHJhbnNsYXRlcyBpbiBhbiBpb21tdSBtYXBwaW5nIGRvd24gYXQKMCBmb3IgdGhlIDMy LWJpdCBzcGFjZSBhbmQgYSBkaXJlY3QgbWFwcGluZyBoaWdoIHVwIGluIHRoZSBQQ0kgYWRkcmVz cwpzcGFjZSAod2hpY2ggY3JvcHMgdGhlIHRvcCBiaXRzIGFuZCB0aHVzIGhpdHMgbWVtb3J5IGF0 IDAgb253YXJkcykuCgpUaGlzIHR5cGUgb2YgaHlicmlkIGxheW91dCBpcyBuZWVkZWQgYnkgc29t ZSBhZGFwdGVycywgdHlwaWNhbGx5CnN0b3JhZ2UsIHdoaWNoIHdhbnQgdG8ga2VlcCB0aGUgImNv aGVyZW50IiBtYXNrIGF0IDMyLWJpdCBidXQgc3VwcG9ydAo2NC1iaXQgZm9yIHN0cmVhbWluZyBt YXNrcy4KCkFub3RoZXIgb25lIHdlIGFyZSB0cnlpbmcgdG8gZGVhbCBiZXR0ZXIgd2l0aCBhdCB0 aGUgbW9tZW50IGlzIGRldmljZXMKd2l0aCBETUEgYWRkcmVzc2luZyBsaW1pdGF0aW9ucy4gU29t ZSBHUFVzIHR5cGljYWxseSAoYnV0IG5vdCBvbmx5KQpoYXZlIGxpbWl0cyB0aGF0IGdvIGFsbCBh Y2Nyb3NzIHRoZSBnYW11dCwgdHlwaWNhbGx5IEkndmUgc2VlbiA0MCBiaXRzLAo0NCBiaXRzIGFu ZCA0NyBiaXRzLi4uIEFuZCBvZiBjb3Vyc2UgdGhvc2UgYXJlICJoaWdoIHBlZm9ybWFuY2UiCmFk YXB0ZXJzIHNvIHdlIGRvbid0IHdhbnQgdG8gbGltaXQgdGhlbSB0byB0aGUgY29tcGFyYXRpdmVs eSBzbWFsbAppb21tdSBtYXBwaW5nIHdpdGggZXh0cmEgb3ZlcmhlYWQuCgpBdCB0aGUgbW9tZW50 LCB3ZSdyZSBsb29raW5nIGF0IGEgZG1hX3NldF9tYXNrKCkgaG9vayB0aGF0IHdpbGwsIGZvcgp0 aGVzZSBndXlzLCByZS1jb25maWd1cmUgdGhlIGlvbW11IG1hcHBpbmcgdG8gY3JlYXRlIGEgImNv bXByZXNzZWQiCmxpbmVhciBtYXBwaW5nIG9mIHN5c3RlbSBtZW1vcnkgKGllLCBza2lwcGluZyB0 aGUgaG9sZXMgd2UgaGF2ZSBiZXR3ZWVuCmNoaXAgb24gUDkgZm9yIGV4YW1wbGUpIHVzaW5nIHRo ZSBsYXJnZXN0IHBvc3NpYmxlIGlvbW11IHBhZ2Ugc2l6ZQooMjU2TSBvbiBQOCwgMUcgb24gUDkp LgoKVGhpcyBpcyBtYWRlIHRyaWNreSBvZiBjb3Vyc2UgYmVjYXVzZSBzZXZlcmFsIGRldmljZXMg Y2FuIHBvdGVudGlhbGx5CnNoYXJlIGEgRE1BIGRvbWFpbiBiYXNlZCBvbiB2YXJpb3VzIHBsYXRm b3JtIHNwZWNpZmljIHJlYXNvbnMuIEFuZCBvZgpjb3Vyc2Ugd2UgaGF2ZSBubyB3YXkgdG8gZmln dXJlIG91dCB3aGF0J3MgdGhlICJjb21tb24gZGVub21pbmF0b3IiIG9mCmFsbCB0aG9zZSBkZXZp Y2VzIGJlZm9yZSB0aGV5IHN0YXJ0IGRvaW5nIERNQS4gQSBkcml2ZXIgY2FuIHN0YXJ0CmJlZm9y ZSB0aGUgbmVpZ2hib3VyIGlzIHByb2JlZCBhbmQgYSBkcml2ZXIgY2FuIHN0YXJ0IGRvaW5nIERN QXMgdXNpbmcKdGhlIHN0YW5kYXJkIDMyLWJpdCBtYXBwaW5nIHdpdGhvdXQgZG9pbmcgZG1hX3Nl dF9tYXNrKCkuCgpTbyBoZXVyaXN0aWNzIC4uLiB1Z2guIEJldHRlciBpZGVhcyB3ZWxjb21lIDot KSBBbGwgdGhhdCB0byBzYXkgdGhhdCB3ZQphcmUgZmFyIGZyb20gYmVpbmcgYWJsZSB0byBnZXQg cmlkIG9mIGRtYV9zZXRfbWFzaygpIGN1c3RvbQppbXBsZW1lbnRhdGlvbnMgKGFuZCBjb2hlcmVu dCBtYXNrIHRvbykuCgpJIHdhcyB0ZW1wdGVkIGF0IHNvbWUgcG9pbnQgcmV0aXJpbmcgdGhlIDMy LWJpdCBpb21tdSBtYXBwaW5nCmNvbXBsZXRlbHksIGp1c3QgZG9pbmcgdGhhdCAibGluZWFyIiB0 aGluZyBJIG1lbnRpb25lZCBhYm92ZSBhbmQKc3dpb3RsYiBmb3IgdGhlIHJlc3QsIGFsb25nIHdp dGggaW50cm9kdWNpbmcgWk9ORV9ETUEzMiBvbiBwb3dlcnBjCih3aXRoIHRoZSByZWFsIDY0LWJp dCBieXBhc3Mgc3RpbGwgYXJvdW5kIGZvciBub24tbGltaXRlZCBkZXZpY2VzIGJ1dAp0aGF0J3Mg dGhlbiBqdXN0IGV4dHJhIHNwZWVkIGJ5IGJ5cGFzc2luZyB0aGUgaW9tbXUgeGxhdGUgJiBjYWNo ZSkuCgpCdXQgSSB3b3JyeSBvZiB0aGUgaW1wYWN0IG9uIHRob3NlIHNpbGx5IGFkYXB0ZXJzIHRo YXQgc2V0IHRoZSBjb2hlcmVudAptYXNrIHRvIDMyLWJpdHMgdG8ga2VlcCB0aGVpciBtaWNyb2Nv ZGUgJiBkZXNjcmlwdG9yIHJpbmcgZG93biBpbiAzMi0KYml0IHNwYWNlLiBJJ20gbm90IHN1cmUg aG93IHdlbGwgWk9ORV9ETUEzMiBiZWhhdmVzIGluIHRob3NlIGNhc2VzLgoKQ2hlZXJzLApCZW4u CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2 ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9s aXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Date: Sat, 24 Jun 2017 15:36:56 +0000 Subject: Re: clean up and modularize arch dma_mapping interface V2 Message-Id: <1498318616.31581.87.camel@kernel.crashing.org> List-Id: References: <20170616181059.19206-1-hch@lst.de> <162d7932-5766-4c29-5471-07d1b699190a@oracle.com> <20170624071855.GD14580@lst.de> In-Reply-To: <20170624071855.GD14580@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Christoph Hellwig , tndave Cc: linux-mips@linux-mips.org, sparclinux@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-ia64@vger.kernel.org, linux-c6x-dev@linux-c6x.org, linux-sh@vger.kernel.org, linux-s390@vger.kernel.org, linux-xtensa@linux-xtensa.org, x86@kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, dmaengine@vger.kernel.org, iommu@lists.linux-foundation.org, openrisc@lists.librecores.org, linux-hexagon@vger.kernel.org, linux-tegra@vger.kernel.org, xen-devel@lists.xenproject.org, linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org On Sat, 2017-06-24 at 09:18 +0200, Christoph Hellwig wrote: > On Wed, Jun 21, 2017 at 12:24:28PM -0700, tndave wrote: > > Thanks for doing this. > > So archs can still have their own definition for dma_set_mask() if > > HAVE_ARCH_DMA_SET_MASK is y? > > (and similarly for dma_set_coherent_mask() when > > CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK is y) > > Any plan to change these? > > Yes, those should go away, but I'm not entirely sure how yet. We'll > need some hook for switching between an IOMMU and a direct mapping > (I guess that's what you want to do for sparc as well?), and I need > to find the best way to do that. Reimplementing all of dma_set_mask > and dma_set_coherent_mask is something that I want to move away from. I think we still need to do it. For example we have a bunch new "funky" cases. We already have the case where we mix the direct and iommu mappings, on some powerpc platforms that translates in an iommu mapping down at 0 for the 32-bit space and a direct mapping high up in the PCI address space (which crops the top bits and thus hits memory at 0 onwards). This type of hybrid layout is needed by some adapters, typically storage, which want to keep the "coherent" mask at 32-bit but support 64-bit for streaming masks. Another one we are trying to deal better with at the moment is devices with DMA addressing limitations. Some GPUs typically (but not only) have limits that go all accross the gamut, typically I've seen 40 bits, 44 bits and 47 bits... And of course those are "high peformance" adapters so we don't want to limit them to the comparatively small iommu mapping with extra overhead. At the moment, we're looking at a dma_set_mask() hook that will, for these guys, re-configure the iommu mapping to create a "compressed" linear mapping of system memory (ie, skipping the holes we have between chip on P9 for example) using the largest possible iommu page size (256M on P8, 1G on P9). This is made tricky of course because several devices can potentially share a DMA domain based on various platform specific reasons. And of course we have no way to figure out what's the "common denominator" of all those devices before they start doing DMA. A driver can start before the neighbour is probed and a driver can start doing DMAs using the standard 32-bit mapping without doing dma_set_mask(). So heuristics ... ugh. Better ideas welcome :-) All that to say that we are far from being able to get rid of dma_set_mask() custom implementations (and coherent mask too). I was tempted at some point retiring the 32-bit iommu mapping completely, just doing that "linear" thing I mentioned above and swiotlb for the rest, along with introducing ZONE_DMA32 on powerpc (with the real 64-bit bypass still around for non-limited devices but that's then just extra speed by bypassing the iommu xlate & cache). But I worry of the impact on those silly adapters that set the coherent mask to 32-bits to keep their microcode & descriptor ring down in 32- bit space. I'm not sure how well ZONE_DMA32 behaves in those cases. Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Jun 2017 17:37:19 +0200 (CEST) Received: from gate.crashing.org ([63.228.1.57]:51875 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23993887AbdFXPhMIX6gA (ORCPT ); Sat, 24 Jun 2017 17:37:12 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id v5OFatdn014035; Sat, 24 Jun 2017 10:36:56 -0500 Message-ID: <1498318616.31581.87.camel@kernel.crashing.org> Subject: Re: clean up and modularize arch dma_mapping interface V2 From: Benjamin Herrenschmidt To: Christoph Hellwig , tndave Cc: linux-mips@linux-mips.org, linux-samsung-soc@vger.kernel.org, linux-ia64@vger.kernel.org, linux-c6x-dev@linux-c6x.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-xtensa@linux-xtensa.org, x86@kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, dmaengine@vger.kernel.org, iommu@lists.linux-foundation.org, openrisc@lists.librecores.org, netdev@vger.kernel.org, sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Date: Sat, 24 Jun 2017 10:36:56 -0500 In-Reply-To: <20170624071855.GD14580@lst.de> References: <20170616181059.19206-1-hch@lst.de> <162d7932-5766-4c29-5471-07d1b699190a@oracle.com> <20170624071855.GD14580@lst.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 58791 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: benh@kernel.crashing.org Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips On Sat, 2017-06-24 at 09:18 +0200, Christoph Hellwig wrote: > On Wed, Jun 21, 2017 at 12:24:28PM -0700, tndave wrote: > > Thanks for doing this. > > So archs can still have their own definition for dma_set_mask() if > > HAVE_ARCH_DMA_SET_MASK is y? > > (and similarly for dma_set_coherent_mask() when > > CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK is y) > > Any plan to change these? > > Yes, those should go away, but I'm not entirely sure how yet. We'll > need some hook for switching between an IOMMU and a direct mapping > (I guess that's what you want to do for sparc as well?), and I need > to find the best way to do that. Reimplementing all of dma_set_mask > and dma_set_coherent_mask is something that I want to move away from. I think we still need to do it. For example we have a bunch new "funky" cases. We already have the case where we mix the direct and iommu mappings, on some powerpc platforms that translates in an iommu mapping down at 0 for the 32-bit space and a direct mapping high up in the PCI address space (which crops the top bits and thus hits memory at 0 onwards). This type of hybrid layout is needed by some adapters, typically storage, which want to keep the "coherent" mask at 32-bit but support 64-bit for streaming masks. Another one we are trying to deal better with at the moment is devices with DMA addressing limitations. Some GPUs typically (but not only) have limits that go all accross the gamut, typically I've seen 40 bits, 44 bits and 47 bits... And of course those are "high peformance" adapters so we don't want to limit them to the comparatively small iommu mapping with extra overhead. At the moment, we're looking at a dma_set_mask() hook that will, for these guys, re-configure the iommu mapping to create a "compressed" linear mapping of system memory (ie, skipping the holes we have between chip on P9 for example) using the largest possible iommu page size (256M on P8, 1G on P9). This is made tricky of course because several devices can potentially share a DMA domain based on various platform specific reasons. And of course we have no way to figure out what's the "common denominator" of all those devices before they start doing DMA. A driver can start before the neighbour is probed and a driver can start doing DMAs using the standard 32-bit mapping without doing dma_set_mask(). So heuristics ... ugh. Better ideas welcome :-) All that to say that we are far from being able to get rid of dma_set_mask() custom implementations (and coherent mask too). I was tempted at some point retiring the 32-bit iommu mapping completely, just doing that "linear" thing I mentioned above and swiotlb for the rest, along with introducing ZONE_DMA32 on powerpc (with the real 64-bit bypass still around for non-limited devices but that's then just extra speed by bypassing the iommu xlate & cache). But I worry of the impact on those silly adapters that set the coherent mask to 32-bits to keep their microcode & descriptor ring down in 32- bit space. I'm not sure how well ZONE_DMA32 behaves in those cases. Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 From: benh@kernel.crashing.org (Benjamin Herrenschmidt) Date: Sat, 24 Jun 2017 10:36:56 -0500 Subject: clean up and modularize arch dma_mapping interface V2 In-Reply-To: <20170624071855.GD14580@lst.de> References: <20170616181059.19206-1-hch@lst.de> <162d7932-5766-4c29-5471-07d1b699190a@oracle.com> <20170624071855.GD14580@lst.de> Message-ID: <1498318616.31581.87.camel@kernel.crashing.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Sat, 2017-06-24 at 09:18 +0200, Christoph Hellwig wrote: > On Wed, Jun 21, 2017 at 12:24:28PM -0700, tndave wrote: > > Thanks for doing this. > > So archs can still have their own definition for dma_set_mask() if > > HAVE_ARCH_DMA_SET_MASK is y? > > (and similarly for dma_set_coherent_mask() when > > CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK is y) > > Any plan to change these? > > Yes, those should go away, but I'm not entirely sure how yet. We'll > need some hook for switching between an IOMMU and a direct mapping > (I guess that's what you want to do for sparc as well?), and I need > to find the best way to do that. Reimplementing all of dma_set_mask > and dma_set_coherent_mask is something that I want to move away from. I think we still need to do it. For example we have a bunch new "funky" cases. We already have the case where we mix the direct and iommu mappings, on some powerpc platforms that translates in an iommu mapping down at 0 for the 32-bit space and a direct mapping high up in the PCI address space (which crops the top bits and thus hits memory at 0 onwards). This type of hybrid layout is needed by some adapters, typically storage, which want to keep the "coherent" mask at 32-bit but support 64-bit for streaming masks. Another one we are trying to deal better with at the moment is devices with DMA addressing limitations. Some GPUs typically (but not only) have limits that go all accross the gamut, typically I've seen 40 bits, 44 bits and 47 bits... And of course those are "high peformance" adapters so we don't want to limit them to the comparatively small iommu mapping with extra overhead. At the moment, we're looking at a dma_set_mask() hook that will, for these guys, re-configure the iommu mapping to create a "compressed" linear mapping of system memory (ie, skipping the holes we have between chip on P9 for example) using the largest possible iommu page size (256M on P8, 1G on P9). This is made tricky of course because several devices can potentially share a DMA domain based on various platform specific reasons. And of course we have no way to figure out what's the "common denominator" of all those devices before they start doing DMA. A driver can start before the neighbour is probed and a driver can start doing DMAs using the standard 32-bit mapping without doing dma_set_mask(). So heuristics ... ugh. Better ideas welcome :-) All that to say that we are far from being able to get rid of dma_set_mask() custom implementations (and coherent mask too). I was tempted at some point retiring the 32-bit iommu mapping completely, just doing that "linear" thing I mentioned above and swiotlb for the rest, along with introducing ZONE_DMA32 on powerpc (with the real 64-bit bypass still around for non-limited devices but that's then just extra speed by bypassing the iommu xlate & cache). But I worry of the impact on those silly adapters that set the coherent mask to 32-bits to keep their microcode & descriptor ring down in 32- bit space. I'm not sure how well ZONE_DMA32 behaves in those cases. Cheers, Ben.