If you aren't familiar with the nvidia binary-only drivers, what you get
is a binary module, and then some source code to wrap it which
translates between the binary module and the kernel.
Back when 2.[56] wasn't properly supported by NV I used to do the odd
bit of hacking to make it work with the new kernel, and from what I
remember there was sti/cli etc in the wrapper code (and that was one of
the incompatibilities at one stage), although not having visibility to
what's in the binary driver I can't say for sure that there is none in
there.
My understanding though, is that NVidia didn't want to reveal any trade
secrets and so released the code that talked to the hardware as a
binary-only driver. If that's the case, there should be no reason why
there'd be anything too nasty in there.
This is also stretching my memory a bit, but I think a few of the nv
developers used to sit on one of the nv related irc channels, maybe
they're still there and might be able to shed some light on the
situation? Anyone comfortable with irc?
The o/s nv drivers are 2d only and don't (afaik) make use of any of the
advanced features on the card for fast 2d or 3d graphics.
James
> -----Original Message-----
> From: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Ian Pratt
> Sent: Tuesday, 13 July 2004 17:04
> To: ron minnich
> Cc: Ian Pratt; xen-devel@xxxxxxxxxxxxxxxxxxxxx; Ian.Pratt@xxxxxxxxxxxx
> Subject: Re: [Xen-devel] results
>
> > On Tue, 13 Jul 2004, Ian Pratt wrote:
> >
> > > If you actually get somewhere with this approach, we could
> > > consider having a special linux GPF handler that decodes the
> > > instruction and patches these up. Barf.
> >
> > you guys have nicely avoided putting in insn decode so far, best
avoided
> > on these horrible CPUs :-0
>
> If Mark's right about there being a 2D driver in the Xserver that
> works without the nvidia binary-only kernel driver, then that's
> definitely the way to go.
>
> I seriously think it's worth a doing a disassembly of the binary
> module and seeing the scale of the problem. If we're lucky and
> it's just the rd/wrmsr that are the problem, they'll be easy to
> deal with by nop'ing them. If there are cli/sti then that's more
> of a pain, but it would actually be pretty easy to do in a Linux
> (as opposed to Xen) GPF handler that spots them and does the
> appropriate Xen call. They're both 1 byte instructions (0xfa/b)
> with no operands, so easy to spot.
>
> As an alternative, you could use static binary rewriting. I'm not
> too familiar with the various x86 binary re-writing tools that
> exist, but perhaps one is up to the job? It's almost do-able with
> objdump -d | awk | gas ;-)
>
> Can anyone recommend a good static binary rewriting tool for x86?
>
> Ian
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/xen-devel
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home