[PATCH] int10: Remove the vm86 and stub backends

[Adam Jackson]

On Tue, 2010-07-27 at 20:23 +0200, Mark Kettenis wrote:
> > Date: Tue, 27 Jul 2010 17:57:01 +0100
> > From: Matthew Garrett <mjg at redhat.com>
> > On Wed, Jul 14, 2010 at 04:15:56PM +0300, Tiago Vignatti wrote:
> > > On Tue, Jul 13, 2010 at 11:32:54PM +0200, ext Adam Jackson wrote:
> > > > vm86 has been defaulted off since 1.6, and is still a terrible idea to
> > > > actually use.  Time to say goodbye.
> > > 
> > > My empirical evidences say that we can't do this. 
> > 
> > The vm86 code is guaranteed to fail in certain circumstances. The most 
> > obvious is anything where the BIOS tries to access address space above 
> > 3GB. We're better off killing it and figuring out where the bugs in 
> > x86emu are.
> 
> How about fixing those bugs before killing it?

Some of them are... nontrivial.

The two big ones I know of are that we don't really emulate unreal mode
properly, and we don't even attempt to emulate MSRs.  This tends not to
matter except on IGP-ish machines, since you'll rarely do that kind of
setup unless you _know_ what kind of processor you're attached to; but
then, those are the sorts of machines people run vesa on...

But I mean, unreal mode mostly doesn't work in vm86 either, and MSR
setup is likely to have been changed by the OS to something the BIOS
isn't expecting, so if/when it works at all with vm86 it's a bit playing
with fire.

I also believe that fixing unreal mode requires a modest amount of
surgery to the int10 harness itself, which is currently subclassed two
ways depending on whether you're doing vm86 or x86emu, which makes it
much harder than it needs to be.  Just to pick one example, go look how
many _different_ real-to-virtual address translation macros there are.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100727/87766297/attachment.pgp>