| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
> 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
|
|
|
| |
|
Home