fa.netbsd.tech.kern
[Top] [All Lists]

Re: rfc: a driver to access MSRs on i386

Subject: Re: rfc: a driver to access MSRs on i386
From: Marc Balmer
Date: Sun, 24 Jan 2010 19:36:14 UTC
Newsgroups: fa.netbsd.tech.kern



Am 24.01.2010 um 20:13 schrieb David Young:

On Sun, Jan 24, 2010 at 06:32:32PM +0100, Marc Balmer wrote:
While porting the xf86-video-geode X.Org driver to NetBSD I also
needed to implement the amdmsr(4) driver I wrote for OpenBSD.  The
issue here is, that xf86-video-geode needs access to several MSRs of
the AMD Geode LX CPU to program the graphics processor. amdmsr(4) is
a driver that allows you todo just this.  It is bound to this
specific type of CPU, whence the strange name.

Does the driver really need to access the MSRs of the Geode LX Graphics Processor? Maybe there is some mistake. Text in the data book suggests
that touching the MSRs is probably unnecessary:

The xf86-video-geode driver was not written by me, and in its current incarnation it needs access to the MSRs.


       The Standard GLD MSRs (accessed via the RDMSR and WRMSR
       instructions) control the Graphics Processor's behavior as
       a GLIU module. These registers should be programmed at
       configuration time and left alone thereafter. They do not
       need to be modified by software to set up any of the graphics
       primitives.

(AMD Geode(tm) LX Processors Data Book, 6.4 Graphics Processor
Register Definitions, p. 254)

It sounds to me that the BIOS or the kernel should initialize the MSRs
and then leave them be.  One of the GP MSRs, BTW, controls the base
address of a 16M "command buffer," a contiguous, non-cacheable physical
memory region (p. 239).

One problem of the driver is, that once it has matched, it allows
access to all MSRs, which can be a security risk (but then, it only
attaches on a AMD Geode LX CPU that has the graphics processor).

I want to extend this on NetNSD, making this a more general and thus
more useable driver.  This is what I have in mind:

Why not provide MI drivers for the abstract functions (e.g., graphics
display, audio playback, encryption/decryption) controlled by these MSRs
instead of for the MSRs themselves?

That would be better, yes. But then other OSs would have to provide similar drivers, too.

So for the time being, I think it is best just to provide what xf86- video-geode needs and what other OSs do as well. And if that means kernel support, we can constrain it to the CPUs in question.

afaik, xf86-vide-intel now also nees kernel support (which we don't have right now) to set video modes.


Can you do without an ioctl for invoking rdmsr/wrmsr if you trap the
instructions and simulate them in the kernel?

I have no idea how to do that.


Dave

--
David Young             OJC Technologies
dyoung@xxxxxxxxxxx      Urbana, IL * (217) 278-3933


<Prev in Thread] Current Thread [Next in Thread>