linux-kernel - Re: [PATCH] PCI: remove pcibios_scan_all

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: <1245714008.4017.7.camel@pasglop>
Date:	Tue, 23 Jun 2009 09:40:08 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Matthew Wilcox <matthew@....cx>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Alex Chiang <achiang@...com>, jbarnes@...tuousgeek.org,
	linux-arch@...r.kernel.org, Kyle McMartin <kyle@...artin.ca>,
	Tony Luck <tony.luck@...el.com>,
	Russell King <linux@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	Yoshinori Sato <ysato@...rs.sourceforge.jp>,
	Jeff Dike <jdike@...toit.com>, linux-kernel@...r.kernel.org,
	Ralf Baechle <ralf@...ux-mips.org>,
	David Howells <dhowells@...hat.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	Ingo Molnar <mingo@...hat.com>,
	"David S. Miller" <davem@...emloft.net>,
	Avi Kivity <avi@...hat.com>
Subject: Re: [PATCH] PCI: remove pcibios_scan_all_fns()

On Mon, 2009-06-22 at 12:30 -0600, Matthew Wilcox wrote:
> 
> That would be correct.  I'm guessing your out-of-tree code sets
> pcibios_scan_all_fns()?
> 
> Now, there are various options.  One is that you could remap config
> space accesses -- domain:bus:dev.fn in the guest don't have to match
> domain:bus:dev.fn in the host.  That's a certain amount of overhead in
> every config space access, but it doesn't have to be a large one.
> 
That's tricky. Some devices have internal registers that -do- depend on
what function they are on. In fact, I remember seeing that in
multifunction devices that are meant to be virtualized but still need to
have some registers be accessed differently depending on the function
(ugh) though don't ask me who that was ...

> Another would be that you could create dummy devices in the guest at
> function 0, and then the guest would scan all the functions.  A little
> ugly, perhaps.

But less ugly than the above.

> A third would be for guests to not do this scanning at all.  You could
> present the devices through something like the openfirmware tree, and
> create them insteaqd of scanning for them.  If you care about startup
> time, this is probably the way to go.

Which is what we do on powerpc nowadays. In fact, this code is currently
inside arch/powerpc and arch/sparc (2 copies slightly diverged) but I
had plans to make it common at move it over to either drivers/of or
drivers/pci (most probably the later).

> There's probably other ways I haven't thought of ...

Well, making up the devices without actual config space probing is nice
and fast but I don't think we want to see too many occurences of such
code in the kernel. We already had breakage once in powerpc land iirc
due to changes in drivers/pci/probe.c that we didn't reflect properly. I
think the normal and OF methods should be enough.

At this stage, it does look to me like a trivial tweak like
pcibios_scan_all_fns() but maybe done a bit nicely, would still be the
simplest solution in term of amount of code involved etc...

Maybe something like

pcibios_get_slot_fn_mask() which returns a bitmask of functions to be
scanned, whose default implementation (weak) would basically check
the header type for function 0 ? As I said, I don't -need- that right
now on powerpc "server" platforms but heh... 

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/