NetBSD Problem Report #21986
Received: (qmail 14461 invoked by uid 605); 25 Jun 2003 07:55:08 -0000
Message-Id: <200306250754.h5P7skk06872@digital.clock.org>
Date: Wed, 25 Jun 2003 00:54:46 -0700 (PDT)
From: "Erik E. Fair" <fair@netbsd.org>
Sender: gnats-bugs-owner@netbsd.org
Reply-To: fair@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: Kernel API needed for finding/configuring GPU
X-Send-Pr-Version: 3.95
>Number: 21986
>Category: kern
>Synopsis: Kernel API needed for finding/configuring GPU
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Wed Jun 25 07:56:00 +0000 2003
>Closed-Date:
>Last-Modified: Wed Jun 25 16:33:00 +0000 2003
>Originator: Erik E. Fair
>Release: NetBSD 1.6
>Organization:
The NetBSD Project
>Environment:
>Description:
NetBSD's primary Xserver is from XFree86. XFree86 does some
very ugly things to find the graphics processing unit(s)
(GPUs) in systems - it scans the PCI/AGP space from user mode.
It should not have to do this, because:
1. this has a serious impact on system integrity (user mode
processes should not, in general, be allowed to poke
individual devices directly like that without kernel
mediation, let alone an entire I/O address space),
2. it hinders portability; we already have a lovely API
for accessing chips in a bus-independent manner, which is
required by the very large number of busses we support
(e.g. PCI, NuBus, Sbus, TURBOChannel, Unibus, MASSbus,
Qbus, etc.). XFree86 should be able to concentrate (for
now) on GPU drivers in a more bus-independent manner.
The NetBSD kernel generally already knows what XFree86 is
attempting to find out (everything is probed at boot time
by autoconfiguration); we simply lack an API to tell
XFree86's Xserver what it wants to know. We should define
such an API, implement it, and both send the changes back
to the XFree86 project, and suggest its adoption by the
other *BSD Projects and Linux.
While this will not solve the security issues involved in
having a user mode process poking a device that can, in
principle, DMA anywhere in RAM it is programmed to, it is
a step in the right direction. With enough step-wise
refinement, we may eventually be able to re-secure the
NetBSD system when X11 is in use.
It should also result in one more manual configuration item
being pulled out of the XFree86Config file, which would remove
a class of user support issues.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: xsrc-manager->kern-bug-people
Responsible-Changed-By: tron
Responsible-Changed-When: Wed Jun 25 07:58:06 UTC 2003
Responsible-Changed-Why:
This is a very good suggestion. But as the synopsis says we need a kernel
API first. This PR belongs therefor in the "kern" category.
Once the kernel API exists a seperate PR can be created about modifying
XFree86 to take advantage of it.
From: Andy Isaacson <adi@hexapodia.org>
To: "Erik E. Fair" <fair@netbsd.org>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: xsrc/21986: Kernel API needed for finding/configuring GPU
Date: Wed, 25 Jun 2003 11:32:31 -0500
On Wed, Jun 25, 2003 at 12:54:46AM -0700, Erik E. Fair wrote:
> NetBSD's primary Xserver is from XFree86. XFree86 does some
> very ugly things to find the graphics processing unit(s)
> (GPUs) in systems - it scans the PCI/AGP space from user mode.
> It should not have to do this, because:
[snip]
> The NetBSD kernel generally already knows what XFree86 is
> attempting to find out (everything is probed at boot time
> by autoconfiguration); we simply lack an API to tell
> XFree86's Xserver what it wants to know. We should define
> such an API, implement it, and both send the changes back
> to the XFree86 project, and suggest its adoption by the
> other *BSD Projects and Linux.
Based on my observation of the XFree86 project, the chances of such an
API replacing their homegrown PCI probing is virtually nil. XFree86
runs on dozens of non-free UNIXes, and they are protective of that
ability.
They might well be willing to add such an API as an alternative,
which should meet your goals -- on systems which provide the API,
XFree86 could use the API, and on other systems it would continue using
the homegrown probing. For such an effort to succeed (that is, be
merged into XFree86 and compiled as part of the standard product) the
API would have to provide every capability provided by the current
scheme, including
- allow X to use multiple GPUs
- allow users to specify which GPU to use (in terms of PCI attach point?)
On many multi-head PC configurations, XFree86 will use its built-in x86
emulation layer to execute the BIOS code contained on the PROM chips on
the non-primary video adapter(s), after frobbing the PCI config space so
that VGA accesses are "correctly" routed to the appropriate card; this
allows them to rely on the BIOS code's initialization of the GPU,
RAMDAC, and so on, rather than having to implement all of that
themselves. (Furthermore, many cards such as ATI OEM cards are
literally impossible to program from scratch. The RAM timings and other
internal GPU register values are dependent on the configuration of the
PCB and the chips installed on it, which are not probeable, and which
configuration information exists solely as a series of x86 instructions
which correctly program the values when run as part of the BIOS startup
sequence.)
> It should also result in one more manual configuration item
> being pulled out of the XFree86Config file, which would remove
> a class of user support issues.
I have a system with 3 GPUs, two of which use the same driver, and only
one of which should be configured and used by XFree86. If you can
support this configuration without requiring me to specify BusID or its
moral equivalent in XF86Config, you have succeeded.
(It's a PC with an ATI, a Matrox Millennium II, and a Matrox G400.)
As an additional point, Keith Packard might have some useful
contributions in this arena. He has talked about starting another
project, separate from XFree86, to remove much of the cruft and to
better support modern systems; I do not know the status of that project.
-andy
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.