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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 3 Apr 2009 16:17:38 +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:
> Some machines (for instance Dell Poweredge servers) disable I/OAT DCA
> support in the BIOS without any way to reenable it.
> DCA may actually be enabled manually it in the processors' MSR and in
> upstream bridge registers. We have been doing this with a hacky userspace
> program, but we feel that the ioatdma driver may actually take care of it.
> 
> Here's a patch doing so, if the ioat_dca_force module parameter is set
> to 1 on load.
> 
> There are some things to improve:
> * Which pcidev should actually get DCA enabled? The patch below looks for
>   Intel upstream bridges. Do we need a check for pdev->is_pcie ? Or maybe
>   even look at pdev->pcie_type? It looks like the pcidev that need to be
>   configured on my machines are PCI_EXP_TYPE_ROOT_PORT, but I am not sure
>   it actually matters. Some Intel people will probably know how to fix this.
> * Any better name for #defin'ing bit #6 at offset 0x64 in the config-space
>   of these bridges?
> 
> Signed-off-by: Brice Goglin <Brice.Goglin@...ia.fr>
> Signed-off-by: Andrew Gallatin <gallatin@...i.com>
> 

Hi Brice,

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.
For these reasons we don't want to include this solution in the ioatdma driver.
Please continue to use the userspace application instead.

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/