linux-kernel - PCI userland access non-mmap APIs, kernel access to legacy space

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]

Message-Id: <1182133004.26853.229.camel@localhost.localdomain>
Date:	Mon, 18 Jun 2007 12:16:44 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	linux-pci@...ey.karlin.mff.cuni.cz
Cc:	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Matthew Wilcox <matthew@....cx>, Greg KH <greg@...ah.com>,
	Ian Romanick <idr@...ibm.com>, Jeff Garzik <jgarzik@...ox.com>
Subject: PCI userland access non-mmap APIs, kernel access to legacy space

Hi folks !

Before I start actually writing code, I want to do a quick brain dump
here to see if there are any objections.

So a problem we have is that on non-x86, we expect to be able to access
PCI IO space via mmap'ing of sysfs based "resource" files.

However, there are various PCI host bridges out there that don't make
that a practical solution. So far, I have two cases on ppc of bridges
that either use indirect access for the IO space or require specific HW
workarounds on accesses that involve spinlocks (to properly deal with
the non-posted aspect of IO transactions). In addition, Lennert tells me
that similar issues exist on ARM.

Thus, I would like to introduce an additional read/write interface to
sysfs "resource" files (and then get Ian's libpciaccess use that when
mmap is unavailable).

In fact, it's funny in a way becauase the "legacy" files interface is
already read/write based (exclusively even, mmap isn't supported) for
legacy IOs.

I beleive that doing so is better than trying to extend /dev/port to
understand multiple domains, >64K IO space, etc... etc...., because you
don't have to understand all the remapping tricks that the operating
system might be doing behind the scene, just open the resource file (or
the legacy file of that bus for legacy accesses) and read/write to it.

Any objection ?

Also, while at it, I would like to introduce a pair of in-kernel
interfaces:

int pci_translate_legacy_resource(struct pci_bus *bus, struct resource *res);

Which takes a resource containing an absolute legacy range on that bus
(for example, an IO resource with the VGA port numbers, or a memory
resource with the VGA text mode aperture). That resource is then
"converted" for the given PCI bus. For x86, that function would boil
down to "return 0;".

The reason is that on multiple domains machines, it's actually not
trivial to figure out where the legacy space of a given domain is
mapped, if available at all. The above function is a way to solve that
problem, allowing things like vgacon to work in multi-domains setup
without half of the current arch specific hacks in there.

That would be also allowed to fail (some platforms can't give access to
legacy memory or legacy IOs at all).

We could probably even implement the pci sysfs "legacy" interface on top
of these as well, thus making it generic to all platforms.

Any objection there too ?

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/