linux-kernel - SNB PCI root information

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-next>] [day] [month] [year] [list]

Date:	Fri, 15 Jun 2012 21:57:27 -0400
From:	Ulrich Drepper <drepper@...il.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	lenb@...nel.org, x86@...nel.org
Subject: SNB PCI root information

The PCI roots in multi-socket SNB are part of specific sockets.  This
means optimization will need to know which socket the root is part of
and therefore which cores have direct access as opposed to over one or
more QPI links.

I tried to find this information in the /sys filesystem in kernels up
to the current upstream kernel.  It seems there is actually nothing
like this.

There are the files /sys/devices/pci*/*/local_cpus which should
contain this information.  For each device we would be able to get the
information about the local CPUs.

The SPARC OF handling seems to set the field, some Intel drivers seem
to try to do it in a different way.

The problem I have seen (at least on a Dell R620) is that the
dev_to_code() function returns -1 which indicates that no node
information is stored.

If I understand the code correctly, the numa_node field can be set
explicitly but is mostly inherited from the underlying device (bus
etc).  Does this mean that the locality information should come from
the same place where the PCI root data structure is initialized?

This happens, if I'm not mistaken, in the ACPI table parsing.  I've
disassembled the DSDT table and didn't find anything like this type of
information.  At least I didn't see it.  I also couldn't find anything
in the ACPI 5.0 spec.

The questions are:
a) am I missing something?
b) do BIOSes (perhaps from other manufacturers) provide the information?
c) can we get this fixed?
d) can we interpolate the information for platforms where the BIOSes
don't have the information?
--
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/