[PATCH] int10: Remove the vm86 and stub backends
vm86 has been defaulted off since 1.6, and is still a terrible idea to
actually use. Time to say goodbye.
The stub backend is only ever built by default on freebsd/ppc, and can't
be doing any good there. The right fix is --disable-int10 if you want
to not ship int10 support.
Signed-off-by: Adam Jackson
---
configure.ac | 15 -
hw/xfree86/int10/Makefile.am | 17 -
hw/xfree86/int10/stub.c| 69 ---
hw/xfree86/os-support/int10Defines.h | 52 +--
hw/xfree86/os-support/linux/int10/linux.c | 544
.../os-support/linux/int10/vm86/linux_vm86.c | 300 ---
hw/xfree86/x86emu/Makefile.am |2 -
include/dix-config.h.in|3 -
8 files changed, 1 insertions(+), 1001 deletions(-)
delete mode 100644 hw/xfree86/int10/stub.c
delete mode 100644 hw/xfree86/os-support/linux/int10/linux.c
delete mode 100644 hw/xfree86/os-support/linux/int10/vm86/linux_vm86.c
diff --git a/configure.ac b/configure.ac
index b3b752c..1a8221e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -332,7 +332,6 @@ dnl
---
dnl Bus options and CPU capabilities. Replaces logic in
dnl hw/xfree86/os-support/bus/Makefile.am, among others.
dnl ---
-DEFAULT_INT10="x86emu"
dnl Override defaults as needed for specific platforms:
@@ -363,9 +362,6 @@ case $host_cpu in
;;
powerpc*)
PPC_VIDEO=yes
- case $host_os in
- *freebsd*) DEFAULT_INT10=stub ;;
- esac
;;
sparc*)
SPARC64_VIDEO=yes
@@ -476,9 +472,6 @@ AC_ARG_ENABLE(unit-tests,
AS_HELP_STRING([--enable-unit-tests],
AC_ARG_ENABLE(use-sigio-by-default,
AS_HELP_STRING([--enable-use-sigio-by-default]
[Enable SIGIO input handlers by default (default: $USE_SIGIO_BY_DEFAULT)]),
[USE_SIGIO_BY_DEFAULT=$enableval], [])
-AC_ARG_WITH(int10, AS_HELP_STRING([--with-int10=BACKEND], [int10
backend: vm86, x86emu or stub]),
- [INT10="$withval"],
- [INT10="$DEFAULT_INT10"])
AC_ARG_WITH(vendor-name, AS_HELP_STRING([--with-vendor-name=VENDOR],
[Vendor string reported by the server]),
[ VENDOR_NAME="$withval" ], [])
@@ -707,14 +700,6 @@ XTRANS_CONNECTION_FLAGS
XTRANS_SECURE_RPC_FLAGS
AM_CONDITIONAL(SECURE_RPC, [test "x$SECURE_RPC" = xyes])
-AM_CONDITIONAL(INT10_VM86, [test "x$INT10" = xvm86])
-AM_CONDITIONAL(INT10_X86EMU, [test "x$INT10" = xx86emu])
-AM_CONDITIONAL(INT10_STUB, [test "x$INT10" = xstub])
-if test "x$INT10" = xyes; then
- dnl VM86 headers
- AC_CHECK_HEADERS([sys/vm86.h sys/io.h])
-fi
-
dnl Handle building documentation
AM_CONDITIONAL(BUILDDOCS, test "x$BUILDDOCS" = xyes)
XORG_ENABLE_DEVEL_DOCS
diff --git a/hw/xfree86/int10/Makefile.am b/hw/xfree86/int10/Makefile.am
index f5ece69..79eb25a 100644
--- a/hw/xfree86/int10/Makefile.am
+++ b/hw/xfree86/int10/Makefile.am
@@ -17,16 +17,6 @@ if I386_VIDEO
I386_VIDEO_CFLAGS = -D_PC
endif
-if INT10_VM86
-AM_CFLAGS = $(I386_VIDEO_CFLAGS) -D_VM86_LINUX $(DIX_CFLAGS) $(XORG_CFLAGS)
$(EXTRA_CFLAGS)
-INCLUDES = $(XORG_INCS)
-libint10_la_SOURCES = \
- $(COMMON_SOURCES) \
- $(srcdir)/../os-support/linux/int10/vm86/linux_vm86.c \
- $(srcdir)/../os-support/linux/int10/linux.c
-endif
-
-if INT10_X86EMU
AM_CFLAGS = $(I386_VIDEO_CFLAGS) -D_X86EMU -DNO_SYS_HEADERS \
$(XORG_CFLAGS) $(EXTRA_CFLAGS) $(DIX_CFLAGS)
INCLUDES = $(XORG_INCS) -I$(srcdir)/../x86emu
@@ -35,12 +25,5 @@ libint10_la_SOURCES = \
xf86x86emu.c \
generic.c \
x86emu.c
-endif
-
-if INT10_STUB
-AM_CFLAGS = $(I386_VIDEO_CFLAGS) -D_VM86_LINUX $(DIX_CFLAGS) $(XORG_CFLAGS)
$(EXTRA_CFLAGS)
-INCLUDES = $(XORG_INCS)
-libint10_la_SOURCES = stub.c xf86int10module.c
-endif
EXTRA_DIST = xf86x86emu.h INT10.HOWTO
diff --git a/hw/xfree86/int10/stub.c b/hw/xfree86/int10/stub.c
deleted file mode 100644
index 58b6578..000
--- a/hw/xfree86/int10/stub.c
+++ /dev/null
@@ -1,69 +0,0 @@
-/*
- * XFree86 int10 module
- * execute BIOS int 10h calls in x86 real mode environment
- * Copyright 1999 Egbert Eich
- */
-#ifdef HAVE_XORG_CONFIG_H
-#include
-#endif
-
-#include "xf86.h"
-#include "xf86str.h"
-#include "xf86_OSproc.h"
-#define _INT10_PRIVATE
-#include "xf86int10.h"
-
-xf86Int10InfoPtr
-xf86InitInt10(int entityIndex)
-{
-return xf86ExtendedInitInt10(entityIndex, 0);
-}
-
-xf86Int10InfoPtr
-xf86ExtendedInitInt10(int entityIndex, int Flags)
-{
-return NULL;
-}
-
-Bool
-MapCurrentInt10(xf86Int10InfoPtr pInt)
-{
-return FALSE;
-}
-
-void
-xf86FreeInt10(xf86Int10InfoPtr pInt)
-{
-return;
-}
-
-void *
-xf86Int10A
[PATCH] int10: Remove the vm86 and stub backends
From: Adam Jackson vm86 has been defaulted off since 1.6, and is still a terrible idea to actually use. Time to say goodbye. The stub backend is only ever built by default on freebsd/ppc, and can't be doing any good there. The right fix is --disable-int10 if you want to not ship int10 support. Signed-off-by: Adam Jackson Reviewed-by: Jamey Sharp --- I'd like to resurrect this patch that ajax proposed a year ago. The thread where it was last discussed is here: http://lists.x.org/archives/xorg-devel/2010-July/011163.html This patch is, as far as I can tell, a correct and complete implementation of removing vm86 and stub. The controversy last time was only over this is the right thing to do. My impression is that everyone agrees that vm86 *should* die, but some commenters were concerned that x86emu didn't support some particularly terrible BIOSes that happened to work on vm86. I'm not convinced that's a sufficient argument for rejecting the patch. The default has been x86emu on everything but Linux/x86-32 since 2005, and x86emu everywhere since 2008. If anybody still cares, please fix up x86emu. configure.ac | 11 - hw/xfree86/int10/Makefile.am | 17 - hw/xfree86/int10/stub.c| 69 --- hw/xfree86/os-support/int10Defines.h | 52 +-- hw/xfree86/os-support/linux/int10/linux.c | 544 .../os-support/linux/int10/vm86/linux_vm86.c | 300 --- hw/xfree86/x86emu/Makefile.am |2 - 7 files changed, 1 insertions(+), 994 deletions(-) delete mode 100644 hw/xfree86/int10/stub.c delete mode 100644 hw/xfree86/os-support/linux/int10/linux.c delete mode 100644 hw/xfree86/os-support/linux/int10/vm86/linux_vm86.c diff --git a/configure.ac b/configure.ac index 06cf9bf..9687f04 100644 --- a/configure.ac +++ b/configure.ac @@ -323,7 +323,6 @@ dnl --- dnl Bus options and CPU capabilities. Replaces logic in dnl hw/xfree86/os-support/bus/Makefile.am, among others. dnl --- -DEFAULT_INT10="x86emu" dnl Override defaults as needed for specific platforms: @@ -354,9 +353,6 @@ case $host_cpu in ;; powerpc*) PPC_VIDEO=yes - case $host_os in - *freebsd*) DEFAULT_INT10=stub ;; - esac ;; sparc*) SPARC64_VIDEO=yes @@ -464,9 +460,6 @@ AC_ARG_ENABLE(debug, AS_HELP_STRING([--enable-debug], AC_ARG_ENABLE(use-sigio-by-default, AS_HELP_STRING([--enable-use-sigio-by-default] [Enable SIGIO input handlers by default (default: $USE_SIGIO_BY_DEFAULT)]), [USE_SIGIO_BY_DEFAULT=$enableval], []) -AC_ARG_WITH(int10, AS_HELP_STRING([--with-int10=BACKEND], [int10 backend: vm86, x86emu or stub]), - [INT10="$withval"], - [INT10="$DEFAULT_INT10"]) AC_ARG_WITH(vendor-name, AS_HELP_STRING([--with-vendor-name=VENDOR], [Vendor string reported by the server]), [ VENDOR_NAME="$withval" ], []) @@ -699,10 +692,6 @@ XTRANS_CONNECTION_FLAGS XTRANS_SECURE_RPC_FLAGS AM_CONDITIONAL(SECURE_RPC, [test "x$SECURE_RPC" = xyes]) -AM_CONDITIONAL(INT10_VM86, [test "x$INT10" = xvm86]) -AM_CONDITIONAL(INT10_X86EMU, [test "x$INT10" = xx86emu]) -AM_CONDITIONAL(INT10_STUB, [test "x$INT10" = xstub]) - dnl Handle installing libxf86config AM_CONDITIONAL(INSTALL_LIBXF86CONFIG, [test "x$INSTALL_LIBXF86CONFIG" = xyes]) diff --git a/hw/xfree86/int10/Makefile.am b/hw/xfree86/int10/Makefile.am index f5ece69..79eb25a 100644 --- a/hw/xfree86/int10/Makefile.am +++ b/hw/xfree86/int10/Makefile.am @@ -17,16 +17,6 @@ if I386_VIDEO I386_VIDEO_CFLAGS = -D_PC endif -if INT10_VM86 -AM_CFLAGS = $(I386_VIDEO_CFLAGS) -D_VM86_LINUX $(DIX_CFLAGS) $(XORG_CFLAGS) $(EXTRA_CFLAGS) -INCLUDES = $(XORG_INCS) -libint10_la_SOURCES = \ - $(COMMON_SOURCES) \ - $(srcdir)/../os-support/linux/int10/vm86/linux_vm86.c \ - $(srcdir)/../os-support/linux/int10/linux.c -endif - -if INT10_X86EMU AM_CFLAGS = $(I386_VIDEO_CFLAGS) -D_X86EMU -DNO_SYS_HEADERS \ $(XORG_CFLAGS) $(EXTRA_CFLAGS) $(DIX_CFLAGS) INCLUDES = $(XORG_INCS) -I$(srcdir)/../x86emu @@ -35,12 +25,5 @@ libint10_la_SOURCES = \ xf86x86emu.c \ generic.c \ x86emu.c -endif - -if INT10_STUB -AM_CFLAGS = $(I386_VIDEO_CFLAGS) -D_VM86_LINUX $(DIX_CFLAGS) $(XORG_CFLAGS) $(EXTRA_CFLAGS) -INCLUDES = $(XORG_INCS) -libint10_la_SOURCES = stub.c xf86int10module.c -endif EXTRA_DIST = xf86x86emu.h INT10.HOWTO diff --git a/hw/xfree86/int10/stub.c b/hw/xfree86/int10/stub.c deleted file mode 100644 index 58b6578..000 --- a/hw/xfree86/int10/stub.c +++ /dev/null @@ -1,69 +0,0 @@ -/* - * XFree86 int10 m
Re: [PATCH] int10: Remove the vm86 and stub backends
Hi! 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. I had different behaviour running some systems with x86emu and vm86 in a not-so-distant past. But it's empirical, as I said; I can't say if the problem in fact is with real mode calls or a mix of the type of real mode with monitor info protocols (DDC1, VBE, I2C, etc.). I gave up tracing it. Also, note we have around fours bugs about people having problems with x86emu - I know this is not a justification to not remove vm86 though: https://bugs.freedesktop.org/show_bug.cgi?id=18160 https://bugs.freedesktop.org/show_bug.cgi?id=9206 https://bugs.freedesktop.org/show_bug.cgi?id=20849 https://bugs.freedesktop.org/show_bug.cgi?id=14332 (Damn, I was very very attempted to s-o-b this patch, Ajax!) > The stub backend is only ever built by default on freebsd/ppc, and can't > be doing any good there. The right fix is --disable-int10 if you want > to not ship int10 support. Makes more sense to separate this hunk in another patch. Thanks, Tiago ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
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. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
> Date: Tue, 27 Jul 2010 17:57:01 +0100 > From: Matthew Garrett > > 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? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
On Tue, 2010-07-27 at 20:23 +0200, Mark Kettenis wrote: > > Date: Tue, 27 Jul 2010 17:57:01 +0100 > > From: Matthew Garrett > > 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 signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
> From: Adam Jackson > Date: Tue, 27 Jul 2010 15:46:59 -0400 > > On Tue, 2010-07-27 at 20:23 +0200, Mark Kettenis wrote: > > > Date: Tue, 27 Jul 2010 17:57:01 +0100 > > > From: Matthew Garrett > > > 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. > > > >=20 > > > > My empirical evidences say that we can't do this.=20 > > >=20 > > > The vm86 code is guaranteed to fail in certain circumstances. The most=20 > > > obvious is anything where the BIOS tries to access address space above=20 > > > 3GB. We're better off killing it and figuring out where the bugs in=20 > > > x86emu are. > >=20 > > How about fixing those bugs before killing it? > > Some of them are... nontrivial. Which makes me seriously doubt that these bugs can be found and fixed fast enough such that users won't be affected. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
On Tue, 2010-07-27 at 22:47 +0200, Mark Kettenis wrote: > > From: Adam Jackson > > Some of them are... nontrivial. > > Which makes me seriously doubt that these bugs can be found and fixed > fast enough such that users won't be affected. Perhaps they can consider running an older X server. - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
On Tue, Jul 27, 2010 at 08:23:05PM +0200, Mark Kettenis wrote: > How about fixing those bugs before killing it? Because right now there's no incentive for anyone to fix those bugs because they can use the vm86 backend instead? -- Matthew Garrett | mj...@srcf.ucam.org ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
On Tue, Jul 27, 2010 at 10:47:05PM +0200, Mark Kettenis wrote: > Which makes me seriously doubt that these bugs can be found and fixed > fast enough such that users won't be affected. If vm86 were an option on anything other than 32-bit x86 I'd have sympathy with retaining it, but it's not a useful fallback if only runs on a tiny fraction of today's machines. Maintaining it requires extra abstraction and makes it harder to fix the x86emu bugs, and while some of the x86emu bugs aren't trivial to fix the vm86 limitations are *impossible* to fix. -- Matthew Garrett | mj...@srcf.ucam.org ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
On Tue, Jul 27, 2010 at 09:46:59PM +0200, ext Adam Jackson wrote: > On Tue, 2010-07-27 at 20:23 +0200, Mark Kettenis wrote: > > > > 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. as I said before, I'm really happy to delete vm86 code - Matthew's arguments are pretty much aligned with mine. But we should guarantee that the myriads of devices X.Org claims to support also run with x86emu. I'd at least ping the guys in those bug reports I pointed and ask what's the state, if works with x86emu, etc. Cheers, Tiago ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
Matthew Garrett wrote: > On Tue, Jul 27, 2010 at 10:47:05PM +0200, Mark Kettenis wrote: > >> Which makes me seriously doubt that these bugs can be found and fixed >> fast enough such that users won't be affected. > > If vm86 were an option on anything other than 32-bit x86 I'd have > sympathy with retaining it, but it's not a useful fallback if only runs > on a tiny fraction of today's machines. Isn't vm86 even further limited to just those machines running the Linux kernel, not BSD or Solaris or anything else? (Okay, maybe that doesn't take a huge chunk out of the number of machines that can run it, but it is replacing one more platform-specific difference with common code.) -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
On Wed, Jul 28, 2010 at 11:29 AM, Alan Coopersmith wrote: > Matthew Garrett wrote: >> On Tue, Jul 27, 2010 at 10:47:05PM +0200, Mark Kettenis wrote: >> >>> Which makes me seriously doubt that these bugs can be found and fixed >>> fast enough such that users won't be affected. >> >> If vm86 were an option on anything other than 32-bit x86 I'd have >> sympathy with retaining it, but it's not a useful fallback if only runs >> on a tiny fraction of today's machines. > > Isn't vm86 even further limited to just those machines running the Linux > kernel, not BSD or Solaris or anything else? (Okay, maybe that doesn't > take a huge chunk out of the number of machines that can run it, but it > is replacing one more platform-specific difference with common code.) Was the vm86 backend disabled by default a few xservers back as well? Alex ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
On Wed, Jul 28, 2010 at 08:29:50AM -0700, Alan Coopersmith wrote: > Isn't vm86 even further limited to just those machines running the Linux > kernel, not BSD or Solaris or anything else? (Okay, maybe that doesn't > take a huge chunk out of the number of machines that can run it, but it > is replacing one more platform-specific difference with common code.) There's no fundamental reason for it to be, but I'll admit that I never actually went to the extent of checking whether there was support code for non-Linux. -- Matthew Garrett | mj...@srcf.ucam.org ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
On Wed, 2010-07-28 at 11:35 -0400, Alex Deucher wrote: > On Wed, Jul 28, 2010 at 11:29 AM, Alan Coopersmith > wrote: > > Isn't vm86 even further limited to just those machines running the Linux > > kernel, not BSD or Solaris or anything else? (Okay, maybe that doesn't > > take a huge chunk out of the number of machines that can run it, but it > > is replacing one more platform-specific difference with common code.) I could have sworn one of the BSDs had implemented a vm86 syscall, but I can't find any reference to it now. It certainly doesn't seem to exist under Solaris. > Was the vm86 backend disabled by default a few xservers back as well? Yep. Which I noted in the original patch email, in fact. - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
On Thu, 29 Jul 2010 13:53:39 -0400, Adam Jackson wrote: > On Wed, 2010-07-28 at 11:35 -0400, Alex Deucher wrote: > > On Wed, Jul 28, 2010 at 11:29 AM, Alan Coopersmith > > wrote: > > > Isn't vm86 even further limited to just those machines running the Linux > > > kernel, not BSD or Solaris or anything else? (Okay, maybe that doesn't > > > take a huge chunk out of the number of machines that can run it, but it > > > is replacing one more platform-specific difference with common code.) > > I could have sworn one of the BSDs had implemented a vm86 syscall, but I > can't find any reference to it now. It certainly doesn't seem to exist > under Solaris. FreeBSD had one. Trying to use it was a huge disaster, emulation was totally the way to go. pgpDHn8eryOFf.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
On Wed, Sep 14, 2011 at 12:25:20 -0500, Jamey Sharp wrote: > From: Adam Jackson > > vm86 has been defaulted off since 1.6, and is still a terrible idea to > actually use. Time to say goodbye. > > The stub backend is only ever built by default on freebsd/ppc, and can't > be doing any good there. The right fix is --disable-int10 if you want > to not ship int10 support. > > Signed-off-by: Adam Jackson > Reviewed-by: Jamey Sharp Acked-by: Julien Cristau Cheers, Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
On Wed, Sep 14, 2011 at 12:25:20PM -0500, Jamey Sharp wrote: > From: Adam Jackson > > vm86 has been defaulted off since 1.6, and is still a terrible idea to > actually use. Time to say goodbye. Not a good idea. I've reenabled it in our enterprise product lately. Reason: I've run into issues with SMIs that were triggered by outb()s to specific registers. These SMIs returned their return state in CPU registers whose values were checked later on in the code. The emulator doesn't track the state of CPU register itself thus will not catch any such results. > > The stub backend is only ever built by default on freebsd/ppc, and can't > be doing any good there. The right fix is --disable-int10 if you want > to not ship int10 support. This was used to handle the request for loading the int10 module and provide targets for the function calls in drivers. If it can be ensured that drivers won't load this module and call its function this can probably be deleted. Cheers, Egbert. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Remove the vm86 and stub backends
On Wed, 2011-09-14 at 19:28 +, Egbert Eich wrote: > On Wed, Sep 14, 2011 at 12:25:20PM -0500, Jamey Sharp wrote: > > From: Adam Jackson > > > > vm86 has been defaulted off since 1.6, and is still a terrible idea to > > actually use. Time to say goodbye. > > Not a good idea. I've reenabled it in our enterprise product lately. > > Reason: I've run into issues with SMIs that were triggered by outb()s > to specific registers. These SMIs returned their return state in CPU > registers whose values were checked later on in the code. > The emulator doesn't track the state of CPU register itself thus > will not catch any such results. Seems like the better solution is to emulate the state machines of those ports. We do a half-baked job of this already for some ports. Actually, the better better solution is "not int10". In general I consider vm86 to be completely unsupportable. Mapping anything at the 0 page means kernel bugs aren't segfaults, which is the kind of security bug that's been actively exploited in the wild. Pretending to care about bugs like the one you describe implies that the affected machine can only work with vesa on i386 and not amd64, and that's not the kind of gotcha I want to enable. int10 services is a losing battle though. Some vendors ship BIOSes that actively flaunt their own documentation about what instructions are legal in vm86 mode (HI INTEL HOW ARE YOU [1]), newer versions of Windows skip it entirely which means it's going to be increasingly unreliable, you might not have int10 at all in EFI, you can't get to unreal mode from vm86 even though some BIOSes expect it... the list goes on. None of this is news though. I've already argued for why vm86 is garbage, and why x86emu is the only thing that can be made to work safely and reliably. If other people want more pain in their lives, that's a thing they can do, people make bad choices all the time and I can't care about every damn thing. [1] - http://lists.fedoraproject.org/pipermail/test/2011-September/102549.html - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
