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:

Home	PR Database Search