linux-kernel - Re: [PATCH] firewire: Enable physical DMA above 4GB

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]

Date:	Fri, 29 Mar 2013 06:50:50 -0400
From:	Peter Hurley <peter@...leysoftware.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	linux1394-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, Clemens Ladisch <clemens@...isch.de>
Subject: Re: [PATCH] firewire: Enable physical DMA above 4GB

On Fri, 2013-03-29 at 11:44 +0100, Stefan Richter wrote:
> On Mar 26 Stefan Richter wrote:
> > On Mar 26 Peter Hurley wrote:
> > > On Tue, 2013-03-26 at 19:56 +0100, Stefan Richter wrote:
> > > > It has been a long time though since I last checked whether PhyUpperBound
> > > > is implemented; maybe it has become more widespread than it was back then.
> > > > 
> > > > Or maybe it hasn't:  All OHCI-1394 chips that ever came to market are 32
> > > > bit chips anyway.  So the few rare ones that do support PhyUpperBound
> > > > larger than 4 GB cannot in fact use it.
> > > > 
> > > > Or am I severely behind the times about this?
> > > 
> > > The FW643e-2 is natively PCIe (not behind a bridge) and supports phys
> > > DMA past 4GB (the datasheet says all 48 bits but I can only test it out
> > > to 10GB).
> > > 
> > > I thought the FW643e was as well? You'll have to test that out :)
> > 
> > OK, will do.
> 
> Does lspci or something similar show which PCI devices are capable of 64 bit
> wide addressing?

Not definitively.

Usually (but not always), if the host registers are 64-bit addressable,
then the device supports DAC. But that's not something that can be
relied on programmatically.

For example, lspci on FW643e-2:
06:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08) (prog-if 10 [OHCI])
	Subsystem: LSI Corporation FW643 [TrueFire] PCIe 1394b Controller
	Flags: bus master, fast devsel, latency 0, IRQ 89
==>	Memory at dbeff000 (64-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: firewire_ohci
	Kernel modules: firewire-ohci

By contrast, lspci on FW323 on same machine:
07:06.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 70) (prog-if 10 [OHCI])
	Subsystem: Dell Device 5811
	Flags: bus master, medium devsel, latency 64, IRQ 30
==>	Memory at dbbff000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: firewire_ohci
	Kernel modules: firewire-ohci


--
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/