linux-kernel - Re: [PATCH 3/3] Add NumaChip quirk

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: <4EA6FB6A.2020800@numascale.com>
Date:	Tue, 25 Oct 2011 20:09:46 +0200
From:	Arne Georg Gleditsch <arne.gleditsch@...ascale.com>
To:	Steffen Persvold <sp@...ascale.com>
CC:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Daniel J Blueman <daniel@...ascale-asia.com>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	H Peter Anvin <hpa@...or.com>, linux-kernel@...r.kernel.org,
	x86@...nel.org, Jesse Barnes <jbarnes@...tuousgeek.org>,
	linux-pci@...r.kernel.org
Subject: Re: [PATCH 3/3] Add NumaChip quirk

On 25. okt. 2011 19:33, Steffen Persvold wrote:
> On 10/25/2011 19:15, Bjorn Helgaas wrote:
>> NumaChip sounds like an exception because you know you never care
>> about using those BARs.  But I'm curious -- it looks like Linux didn't
>> even try to assign resources to them.  I thought something in the
>> pci_assign_unassigned_resources() path would have tried to do
>> something with them.  If we *did* assign resources to those BARs, I
>> assume nothing would break, since there's no driver that actually uses
>> them.  Right?
>>
> 
> Correct, the BARs are there and if something sensible were written to
> them (and MemorySpace was enabled in the Command register) NumaChip
> *would* respond to mmio accesses to that address range.

A minor point: adjusting the BARs would not strictly speaking be
sufficient for the NumaChip to respond, as it would never see these
accesses unless the [MMIO address range]->[HyperTransport node/link]
registers of the CPU NorthBridges were also updated with the relevant
ranges.  This is a bit messy, but in a way much the same issue as when
secondary southbridges are connected to secondary CPUs in any other
HyperTransport-based system.

Perhaps an alternative to this NumaChip-specific quirk would be to
special-case BARs belonging to "PCI" devices 00:18 - 00:1f in AMD
Opteron systems.  These always indicate coherent HT devices and fiddling
with the CPU NB maps are going to be required if anything is changed
regarding the BAR assignments here.

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