[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] nvidia
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |