I think the real issue is that AMD neither recommends nor supports this
strategy. ( http://www.x86-64.org/lists/discuss/msg02964.html ... there were
better posts but I couldn't find them) People with real hardware can't talk
about it right now, but it seems to me this is just begging to get hit by
errata -- how much effore do you think team Hammer spent testing a subtle
mode transition which is marked "Don't do that!" ?
> > > emulators sounds much better, especially in the long run. But it can
> > > be written.
> >
> > For DOS even a slow emulator should be good enough. After all most
> > DOS Programs are written for slow machines. Bochs running on a K8
> > will be hopefully fast enough. If not an JIT can be written, perhaps
> > you can extend valgrind for it.
> >
> > Or if you really rely on a DOS program executing fast you can
> > always boot a 32bit kernel which of course still supports vm86
> > in legacy mode.
>
> While an emulator sounds like a good idea, it is baggage that needs to be
> included. JIT is probably overkill if the hardware can already do it.
I am actually working on a dynamic translator for x86, and am starting with
16-bit real-mode. It's a bit OT for linux-kernel, and it's not done yet so
I'll spare you the details, but the point is that the kernel doesn't need to
do anything special to help an emulator/dynamic translator, and that it
*shouldn't* let you run real-mode code on the hardware.
> I contend that if the thunking code is reasonably well defined and thought
> out, jumping in & out of long mode might not be as big a hassle as
> originally thought.
Even the best code is subject to the limitations of the hardware it is run on.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/