linux-kernel - Re: Probing unconfigured PCI bridge resouces

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: <1327702566.24487.26.camel@pasglop>
Date:	Sat, 28 Jan 2012 09:16:06 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	linux-pci@...r.kernel.org,
	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: Probing unconfigured PCI bridge resouces

On Fri, 2012-01-27 at 09:36 -0800, Jesse Barnes wrote:

> > Ok, I think I was missing pci_bridge_check_ranges(), gotta figure now
> > why this didn't kick in properly for me, probably some arch code
> > crackpot.
> > 
> > One thing I noticed is that we do clear IORESOURCE_UNSET in setup-res.c
> > when setting up a device resource but we don't clear it for bridges in
> > generic code ever, so it leaks all the way through from my early arch
> > code. Not a big deal but annoying.
> 
> Maybe you can fix that when you unify your arch resource handling code
> with the core one day. :)
> 
> There have been a lot of changes to handle re-allocation and such, and
> I'm sure there's more duplication now...

There isn't much the my arch does that isn't just calling into core
nowadays on powerpc, look at my resource survey :-)

I have some slightly different (arguably better ?) logic to deal with
unassigned resources in the initial allocation pass before re-assigning
(or assigning unassigned) and flags to enable ignoring the initial state
of devices (which should be improved with core changes one of these
days, for example we still read all bridge bases even when we know we
are just going to re-assign everything etc...).

The one thing I cannot unify is actually new in 3.3, it's the code to
assign resources on the new "powernv" platform which requires its own
logic unfortunately and I'm not sure I can make the core do what I want
without major uglyness.

The main reason is that on p7ioc and similar recent IBM host bridges, we
have a domain mechanism which allows error isolation, dma isolation
etc... which also encompass MMIO (in order to properly assign MMIO
errors such as target aborts etc... with a domain).

The way this works is by segmenting the MMIO space, which means that all
BARs of a all devices in a given domain shall be assigned to a group of
segments. Now I -can- renumber 32-bit segments so in theory I could get
away with alignment tricks (tho nasty ones) only but I can't always
renumber 64-bit segments (tho in my current scheme I simply don't use
64-bit MMIO segments at all, in part due to that complication).

The consequence is that I need to pre-assign domains at boot based on
various constraints and policy decisions which unfortunately have to be
made by the kernel arbitrarily, and then tweak the MMIO resource
allocation to assign BARs of devices accordingly so they fit into
"segments" that can be made to correspond with the domains.

Cheers,
Ben.

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