linux-kernel - RE: [RFC] ioat-dca: force I/OAT DCA when disabled in BIOS

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 for Android: free password hash cracker in your pocket

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

Message-ID: <129600E5E5FB004392DDC3FB599660D791087894@irsmsx504.ger.corp.intel.com>
Date:	Thu, 9 Apr 2009 14:03:53 +0100
From:	"Sosnowski, Maciej" <maciej.sosnowski@...el.com>
To:	Brice Goglin <Brice.Goglin@...ia.fr>
CC:	"Andrew J. Gallatin" <gallatin@...i.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: RE: [RFC] ioat-dca: force I/OAT DCA when disabled in BIOS

Brice Goglin wrote:
>> While this patch should work for some platforms (with I/OAT devices of IDs: 0x1a38, 0x360b,
>> 0x65ff) it is not a platform generic solution. Generally enabling DCA, like this dca_force()
>> routine does, requires other settings including the tag_map which should be set by BIOS. Thus
>> it should be BIOS responsibility to prepare the whole required configuration for DCA. 
> 
> Well, that's exactly the reason why the patch only enforces DCA when
> ioat_dca_force=1 is given. We obviously don't want to tweak registers
> like this by default, unless the admin knows what he is doing.

As we can't guarantee that dca_force() should work on all platforms,
we can't accept adding this functionality as a part of the driver - even if it's disbled by default.
If an admin wishes to take a chance he can use the userspace program.

> Having to run a custom script is really annoying for many Dell machine
> users where the tag_map is already correctly set by the BIOS. And you
> have to make sure that the script runs before ioatdma is loaded (which
> means you cannot built ioatdma inside the kernel, by the way).
> 
> By the way, do you have some ideas about how to filter bridges better?
> Maybe somebody at Intel has a whitelist of intel bridges that could be
> involved here?

What I found is that the list will be all root ports for the 5000-series chipset (Blackford),
5100-series chipset (San Clemente), 7300 chipset (Caneland).
The register does not exist for 5400 chipset (Seaburg).

Regards,
Maciej--
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/