linux-kernel - RE: [PATCHv4] DMAEngine: Define interleaved transfer request api

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0CE8B6BE3C4AD74AB97D9D29BD24E55202367258@CORPEXCH1.na.ads.idt.com>
Date:	Tue, 18 Oct 2011 10:26:56 -0700
From:	"Bounine, Alexandre" <Alexandre.Bounine@....com>
To:	Russell King <rmk@....linux.org.uk>,
	Jassi Brar <jaswinder.singh@...aro.org>
CC:	"Williams, Dan J" <dan.j.williams@...el.com>,
	Vinod Koul <vinod.koul@...el.com>,
	Barry Song <21cnbao@...il.com>, <linux-kernel@...r.kernel.org>,
	DL-SHA-WorkGroupLinux <workgroup.linux@....com>,
	Dave Jiang <dave.jiang@...el.com>
Subject: RE: [PATCHv4] DMAEngine: Define interleaved transfer request api

On Tue, Oct 18, 2011 at 5:50 AM, Russell King <rmk@....linux.org.uk> wrote:
> 
> On Tue, Oct 18, 2011 at 02:00:45PM +0530, Jassi Brar wrote:
> > On 18 October 2011 13:12, Russell King <rmk@....linux.org.uk> wrote:
> > > On Tue, Oct 18, 2011 at 11:15:29AM +0530, Jassi Brar wrote:
> > >> On 18 October 2011 02:37, Bounine, Alexandre
> <Alexandre.Bounine@....com> wrote:
> > >> > With item #1 above being a separate topic, I may have a problem
> with #2
> > >> > as well: dma_addr_t is sized for the local platform and not
> guaranteed
> > >> > to be a 64-bit value (which may be required by a target).
> > >> > Agree with #3 (if #1 and #2 work).
> > >> >
> > >> Perhaps simply change dma_addr_t to u64 in dmaengine.h alone ?
> > >
> > > That's just an idiotic suggestion - there's no other way to put
> that.
> > > Let's have some sanity here.
> > >
> > Yeah, I am not proud of the workaround, so I only probed the option.
> > I think I need to explain myself.
> >
> > The case here is that even a 32-bit RapidIO host could ask transfer
> against
> > 64-bit address space on a remote device. And vice versa 64->32.
> >
> > > dma_addr_t is the size of a DMA address for the CPU architecture
> being
> > > built.  This has no relationship to what any particular DMA engine
> uses.
> > >
> > Yes, so far the dmaengine ever only needed to transfer within
> platform's
> > address-space. So the assumption that src and dst addresses could
> > be contained within dma_addr_t, worked.
> > If the damengine is to get rid of that assumption/constraint, the
> memcpy,
> > slave_sg etc need to accept addresses specified in bigger of the host
> and
> > remote address space, and u64 is the safe option.
> > Ultimately dma_addr_t is either u32 or u64.
> 
> Let me spell it out:
> 
> 1. Data structures read by the DMA engine hardware should not be
> defined
>    using the 'dma_addr_t' type, but one of the [bl]e{8,16,32,64} types,
>    or at a push the u{8,16,32,64} types if they're always host-endian.
> 
>    This helps to ensure that the layout of the structures read by the
>    hardware are less dependent of the host architecture and each
> element
>    is appropriately sized (and, with sparse and the endian-sized types,
>    can be endian-checked at compile time.)
> 
> 2. dma_addr_t is the size of the DMA address for the host architecture.
>    This may be 32-bit or 64-bit depending on the host architecture.
> 
> The following points are my opinion:
> 
> 3. For architectures where there are only 32-bit DMA addresses,
> dma_addr_t
>    will be a 32-bit type.  For architectures where there are 64-bit DMA
>    addresses, it will be a 64-bit type.
> 
> 4. If RIO can accept 64-bit DMA addresses but is only connected to 32-
> bit
>    busses, then the top 32 address bits are not usable (it's truncated
> in
>    hardware.)  So there's no point passing around a 64-bit DMA address.

Existing RapidIO controllers offer an address translation mechanism for
inbound RIO requests which will translate RIO address into an address of
mapped endpoint's local buffer. Some less-generic endpoints may also use
upper address bits for their own implementation specific mapping and this
is absolutely legal from the RIO POV. As an example of similar use may be
a PCI bus where upper AD lines are used for device selection during PCI
configuration cycles.       

So RIO addresses of any size are not blindly truncated and cannot be ignored.
  
> 
> 5. In the case of a 64-bit dma_addr_t and a 32-bit DMA engine host
> being
>    asked to transfer >= 4GB, this needs error handing in the DMA engine
>    driver (I don't think its checked for - I know amba-pl08x doesn't.)
> 
> 6. 32-bit dma_addr_t with 64-bit DMA address space is a problem and is
>    probably a bug in itself - the platform should be using a 64-bit
>    dma_addr_t in this case.  (see 3.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/