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]

Date:	Tue, 25 Oct 2011 14:03:08 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Arne Georg Gleditsch <arne.gleditsch@...ascale.com>
Cc:	Steffen Persvold <sp@...ascale.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 Tue, Oct 25, 2011 at 12:09 PM, Arne Georg Gleditsch
<arne.gleditsch@...ascale.com> wrote:
> 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.

The [MMIO address range]->[HyperTransport node/link] registers you're
talking about are the implementation side of the PCI host bridge
abstraction.  You should have an ACPI host bridge device (PNP0A03 or
PNP0A08) that describes the apertures, and if Linux assigns resources
to the BARs, it will only use areas inside the apertures.  If there's
no available space in the apertures, we just leave the device alone
(maybe this explains why we didn't assign anything).

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

I don't think there's a need to special-case these AMD BARs.  If the
BIOS programs them correctly (inside a PCI host bridge aperture
reported via ACPI), Linux won't touch them.

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