Re: [Xen-devel] results

[Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>]

> 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