Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Andi Kleen]

Kevin Lawton <kevinlawton2001@yahoo.com> writes:
> 
> I'm working on running Linux as a guest OS inside a
> lightweight cut-down plex86 environment.  My goal is to
> run a stock Linux kernel, which can be slimmed down to

Wouldn't it be easier if you just compile the kernel 
with a simple gcc wrapper that replaces all pushfl and popfl with your new 
sequences in the assembly code generated by gcc and also in assembly files 
compiled with the gcc wrapper?

I guess that would avoid much maintenance hazzle long term

-Andi

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Kevin Lawton]

--- Andi Kleen <ak@suse.de> wrote:
> Kevin Lawton <kevinlawton2001@yahoo.com> writes:
> > 
> > I'm working on running Linux as a guest OS inside a
> > lightweight cut-down plex86 environment.  My goal is to
> > run a stock Linux kernel, which can be slimmed down to
> 
> Wouldn't it be easier if you just compile the kernel 
> with a simple gcc wrapper that replaces all pushfl and popfl with your new 
> sequences in the assembly code generated by gcc and also in assembly files 
> compiled with the gcc wrapper?

I'm not big on the idea of scripts massaging code - especially when
they do something unintended.  It's easier to run a periodic find
script that greps for use of such instructions, if new cases
are introduced.  Anyways, there were really only a few cases where
pushf/popf would have even mattered.  Some stuff was just
EFLAGS.{ID/AC} identification.  I greatly prefer the #define mods.

The new kernel source was quite clean of this stuff, and did a great
job centrailizing stuff in include/asm-i386.

-Kevin

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Kevin Lawton]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

OK, here's my re-submit of patches, after some great
clean-up/simplification ideas from Andrew Morton and Andi Kleen.

There are now no mods to any *.{c,S,h} files.  Here's
a summary of the mods:

  o Added 'Documentation/x86-hal.txt'
  o Simple mods to 'Makefile'
  o Added menu entry to 'arch/i386/Kconfig'
  o Simple mod to 'arch/i386/boot/Makefile'
  o Added 'include/asm-i386/if.h'

Only when compiling after enabling this new option,
the Makefile forces inclusion of the 'if.h' file, which
macro'izes the use of PUSHF/POPF instructions, substituting
a few lines of code which fix the broken-ness of such
logic when running with PVI (protected mode virtual interrupts).
No of this would be necessary if the VME (for vm86) semantics
were carried over to PVI.

Also, I'm including the 'Documentation/x86-hal.txt' to
state my case for getting these mods in sooner than later,
and to familiarize folks with what they're for.  My bad,
not explaining it better the 1st time.

-Kevin

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

[-- Attachment #2: linux-2.5.59-hal.diffs --]
[-- Type: application/octet-stream, Size: 12095 bytes --]

diff -urN linux-2.5.59/Documentation/x86-hal.txt linux-2.5.59-hal/Documentation/x86-hal.txt
--- linux-2.5.59/Documentation/x86-hal.txt	Wed Dec 31 19:00:00 1969
+++ linux-2.5.59-hal/Documentation/x86-hal.txt	Wed Jan 22 18:37:44 2003
@@ -0,0 +1,114 @@
+x86 Hardware Abstraction Layer
+==============================
+
+Maintained by Kevin P. Lawton <kevinlawton2001@yahoo.com>
+Last updated: Wed Jan 22 17:05:05 EST 2003
+
+The goal of the x86 hardware abstraction layer is to provide
+a way to run the mainstream x86 Linux kernel as a guest OS, in
+a lightweight Virtual Machine (VM), provided by a new cut-down
+plex86 port.  For reference, see the section on plex86.
+
+The idea being, to have the ability to configure/compile x86 Linux
+"out-of-the-box", disabling lots of unnecessary host-oriented
+hardware support, and running it unpatched inside a special
+VM container.
+
+Because the VM understands that a VM'able guest OS is running,
+_many_ of the heavy x86 VM techniques are unnessary, and only
+the core set of IO functionality needs to be emulated; things
+like the interrupt controller, timers, straight text-mode
+VGA frame buffer, and other things which are very lightweight
+to emulate.  References to these devices can be easily monitored
+by a VM monitor, without modification to the Linux kernel.
+
+The functionality of heavy IO devices like disk/network, are
+best handled by efficient loadable kernel modules designed for
+Linux as a guest.  These modules can communicate a hardware
+abstraction layer protocol to the host OS outside the VM
+to handle the IO workload independently by the host OS,
+which is likely Linux (of course!).
+
+
+Why a Linux VM?
+===============
+
+  o Ability to have multiple Linux installations on one machine
+    at your disposal, with various software configuations.
+    This is great for developers, and call-in support centers
+    who need to have a matrix of OS/application versions
+    available.
+
+  o Security.  There are tons of applications here.  Firewalling
+    of certain applications, honey-pots, ...  I'll let the
+    security guys fill in this category.
+
+  o Provisioning of server resources.  Having the ability to
+    consolidate servers to optimize the use of each CPU.  And
+    to dynamically spin up servers on-demand.  Lots of
+    consoliation and load-balancing plays here.
+
+  o Ability to log into a specific/personal VM "context"
+    from across the Internet, but to have the VM centrally
+    located (and maintained) on servers.  The "context"
+    is the particular Linux install with all of the
+    user-specific files.
+
+
+What is plex86?
+===============
+
+Plex86 is an x86 virtual machine project.  Though it's a separate
+entity, it is currently a subdirectory of "bochs", an x86 PC
+emulation project which can be found on
+
+  http://bochs.sourceforge.net/
+
+Originally, the goals of plex86 were to run any guest OS
+inside the VM, which required some heavy trickery.  I
+completely gutted plex86, and now it is an incredibly
+small and lightweight x86 VM, meant to run code which
+is "VM friendly".  Or in other words, if you don't need to
+run non-Linux, you don't need 99% of the VM baggage.
+
+Plex86 is not ready yet for running Linux as a guest, but I do
+have it working in tandem with bochs to run Linux user-level
+code inside the VM.
+
+
+How much does it cost?
+======================
+
+Nothing, it's Open Source.  Linux is obviously a GPL'd program.
+Plex86 is an LGPL'd kernel module.  Though it's a separate
+
+
+What kind of modifications to the Linux kernel are needed?
+==========================================================
+
+The ideal answer would be none.  The goal is to run the
+actual x86 codebase, with the aim for this to be usable in
+enterprise-level settings.  Thus, it's much more appealing
+not to have modifications, but to leverage all the
+testing that the main codebase goes through.
+
+So far, there are just a couple x86 instructions which
+can be easily macro'ized to change their behaviour, relating
+to manipulation of the interrupt flag.  This is due to
+a deficiency in the handling of code running with Protected
+mode Virtual Interrupts (PVI).  Thus far, the code impact
+is one extra header file, and a few lines to conditionally
+include it!
+
+I am _really_ hoping these small mods make it into the main
+kernel base before Linux 2.6.0.  I believe there will be
+commercial thrust behind running Linux VMs, and would like
+to see the ability to compile kernel source included with
+the major Linux distros, as-is with no extra patches.
+
+For kernel modules which are developed to facilitate a
+Linux VM communicating HAL protocol to the host Linux,
+I have no religion.  They can be maintained wherever makes
+sense.
+
+-Kevin
diff -urN linux-2.5.59/Makefile linux-2.5.59-hal/Makefile
--- linux-2.5.59/Makefile	Wed Jan 22 12:25:58 2003
+++ linux-2.5.59-hal/Makefile	Wed Jan 22 22:36:00 2003
@@ -264,6 +264,18 @@
 CFLAGS		+= -fomit-frame-pointer
 endif
 
+ifdef CONFIG_X86_HAL
+# On x86, if compiling for the Hardware Abstraction Layer
+# (running Linux as a guest OS in a Virtual Machine),
+# we need to insert some asm macros which redefine
+# the behaviour of instructions which modify the
+# interrupt flag.  You are probably not configuring for
+# this mode.  For more info, read 'Documentation/x86-hal.txt'.
+# This needs to be the first include any module sees.
+CFLAGS		+= -include include/asm/if.h
+AFLAGS		+= -include include/asm/if.h
+endif
+
 #
 # INSTALL_PATH specifies where to place the updated kernel and system map
 # images.  Uncomment if you want to place them anywhere other than root.
@@ -409,6 +421,10 @@
 #	their vmlinux.lds.S file
 
 AFLAGS_vmlinux.lds.o += -P -C -U$(ARCH)
+
+ifdef CONFIG_X86_HAL
+AFLAGS_vmlinux.lds.o += -DNO_X86_HAL_INCLUDES
+endif
 
 arch/$(ARCH)/vmlinux.lds.s: %.s: %.S scripts FORCE
 	$(call if_changed_dep,as_s_S)
diff -urN linux-2.5.59/arch/i386/Kconfig linux-2.5.59-hal/arch/i386/Kconfig
--- linux-2.5.59/arch/i386/Kconfig	Wed Jan 22 12:25:59 2003
+++ linux-2.5.59-hal/arch/i386/Kconfig	Wed Jan 22 23:41:11 2003
@@ -1661,3 +1661,20 @@
 	bool
 	depends on SMP
 	default y
+
+menu "Hardware Abstraction Layer"
+
+config X86_HAL
+	bool "Compile for HAL (experimental)"
+	depends on !HIGHMEM && !SMP && !M486 && !M386 && !X86_UP_APIC && !X86_UP_IOAPIC
+	help
+    Experimental: Say Y here _only_ if you are compiling Linux to run inside
+    an experimental Hardware Abstraction Layer.  This is only useful
+    for running Linux as a guest OS in a special virtual machine.
+    Say N here unless you absolutely know what this is for.  This
+    will break Linux running on a real machine for sure.  This option
+    has the following configuration constraints: Pentium or higher,
+    uniprocessor mode, no apic support.  For more info see
+    <file:Documentation/x86-hal.txt>.
+
+endmenu
diff -urN linux-2.5.59/arch/i386/boot/Makefile linux-2.5.59-hal/arch/i386/boot/Makefile
--- linux-2.5.59/arch/i386/boot/Makefile	Tue Jan 14 00:58:35 2003
+++ linux-2.5.59-hal/arch/i386/boot/Makefile	Wed Jan 22 22:52:40 2003
@@ -32,6 +32,10 @@
 
 host-progs	:= tools/build
 
+ifdef CONFIG_X86_HAL
+AFLAGS += -DNO_X86_HAL_INCLUDES
+endif
+
 # ---------------------------------------------------------------------------
 
 $(obj)/zImage:  IMAGE_OFFSET := 0x1000
diff -urN linux-2.5.59/include/asm-i386/if.h linux-2.5.59-hal/include/asm-i386/if.h
--- linux-2.5.59/include/asm-i386/if.h	Wed Dec 31 19:00:00 1969
+++ linux-2.5.59-hal/include/asm-i386/if.h	Wed Jan 22 22:35:02 2003
@@ -0,0 +1,157 @@
+#ifndef NO_X86_HAL_INCLUDES
+/*
+ *	Routines to manipulate the interrupt flag (EFLAGS.IF).  Abstracting
+ *	them, makes it easier to compile for a hardware abstraction layer (HAL).
+ *
+ *	(c) 2003 Kevin P. Lawton <kevinlawton2001@yahoo.com>
+ */
+
+#ifndef _LINUX_ASM_IF_H_
+#define _LINUX_ASM_IF_H_
+
+
+/* NOTE: This file is directly included via the "-include include/asm/if.h"
+ * option conditionally added to the compiler flags by the top Makefile when
+ * CONFIG_X86_HAL is defined.  None of the header files have been included
+ * at this point.
+ */
+
+/* For a HAL (Hardware Abstraction Layer) compile, the kernel is executed
+ * at PL=3 using PVI (Protected mode Virtual Interrupts), which are the
+ * analog to VME for v86 code.  For some reason, The Creators stopped short of
+ * implementing proper IF handling for PUSHF/POPF for PVI, but STI/CLI are
+ * fine.  So we have to complete the PVI semantics using the following
+ * sequences.
+ */
+
+/* Shield your eyes.  These macros make it possible to use the same
+ * code for asm or C inline asm, with all the quoting, comma, and
+ * newline issues.  Q1 is for lines with no commas, and Q2 is for lines
+ * with one comma.
+ */
+#ifdef __ASSEMBLY__
+#define Q1(s0)     s0
+#define Q2(s0, s1) s0, s1
+#else
+#define Q1(s0)     #s0 "\n\t"
+#define Q2(s0, s1) #s0 "," #s1 "\n\t"
+#endif
+
+
+#ifndef __ASSEMBLY__
+__asm__ (
+#endif
+
+  Q1(.macro  cli)
+  Q1(.byte 0xfa)     /* cli (native instruction works fine in PVI) */
+  Q1(.endm)
+
+  Q1(.macro  sti)
+  Q1(.byte 0xfb)     /* sti (native instruction works fine in PVI) */
+  Q1(.endm)
+
+#ifndef __ASSEMBLY__
+  );
+#endif
+
+
+
+/* PUSHFL:
+ * When execution is monitored using PVI (Protected mode Virtual Interrupts),
+ * we have to complete the PVI semantics of the PUSHFL instruction, as
+ * per behaviour of VME.
+ *
+ *                        b19           b9
+ * CPU   image of eflags: VIF           IF
+ *                         |
+ *                         +------------+
+ *                                      |
+ *                                      v
+ * Stack image of eflags: VIF           IF
+ *
+ * Notes: VIF on the stack image could be cleared, if it matters.
+ */
+
+#ifndef __ASSEMBLY__
+__asm__ (
+#endif
+
+  Q1(  .macro pushfl)
+  Q1(  .byte 0x9c)                /* (pushfl) Final eflags stack image. */
+  Q1(  .byte 0x9c)                /* (pushfl) For restoring arith flags. */
+  Q2(  testl $(1<<19), 4(%esp))   /* Was VIF bit set? */
+  Q1(  jz 69001f)
+  Q2(  orl   $(1<<9), 4(%esp))    /* Yes: set stack image of IF. */
+  Q1(  jmp 69002f)
+  Q1(69001:)                      /* Use the zip of Lyon France :^} */
+  Q2(  andl  $~(1<<9), 4(%esp))   /* No: clear stack image of IF. */
+  Q1(69002:)
+  Q1(  .byte 0x9d)                /* (popfl) Restore arithmetic flags. */
+  Q1(  .endm)
+
+  /* The user may use pushf with an implicit size.  Just expand that
+   * to the previous macro.
+   */
+  Q1(.macro pushf)
+  Q1(pushfl)
+  Q1(.endm)
+
+#ifndef __ASSEMBLY__
+  );
+#endif
+
+
+
+/* POPFL:
+ * When execution is monitored using PVI (Protected mode Virtual Interrupts),
+ * we have to complete the PVI semantics of the POPFL instruction, as
+ * per behaviour of VME.
+ *
+ *                        b19           b9
+ * Stack image of eflags: VIF           IF
+ *                                      |
+ *                         +------------+
+ *                         |
+ *                         v
+ * CPU   image of eflags: VIF           IF
+ *
+ * Notes: IF of the eflags register retains its previous value, which
+ *   should be 1 (when monitored down to PL3, the processor ignores this
+ *   bit in a POPF).
+ */
+
+#ifndef __ASSEMBLY__
+__asm__ (
+#endif
+
+  Q1(  .macro popfl)
+  Q2(  testl $(1<<9), 0(%esp))    /* Is IF set on stack image? */
+  Q1(  jz 69003f)
+  Q1(  .byte 0x9d)                /* (popfl) Yes: restore from stack and */
+  Q1(  sti)                       /* force VIF=1. */
+  Q1(  jmp 69004f)
+  Q1(69003:)
+  Q1(  .byte 0x9d)                /* (popfl) No: restore from stack and */
+  Q1(  cli)                       /* force VIF=0. */
+  Q1(69004:)
+  Q1(  .endm)
+
+  /* The user may use popf with an implicit size.  Just expand that
+   * to the previous macro.
+   */
+  Q1(.macro popf)
+  Q1(popfl)
+  Q1(.endm)
+
+#ifndef __ASSEMBLY__
+  );
+#endif
+
+/* Get rid of quoting macros - good housekeeping. */
+#undef Q1
+#undef Q2
+
+
+#endif  /* _LINUX_ASM_IF_H_ */
+
+#endif  /*  NO_X86_HAL_INCLUDES */

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Kai Germaschewski]

On Wed, 22 Jan 2003, Kevin Lawton wrote:

Three minor points:

o If you included the patch inline instead of as application/octet-stream, 
  it'd be easier to reply ;)

> +Nothing, it's Open Source.  Linux is obviously a GPL'd program.
> +Plex86 is an LGPL'd kernel module.  Though it's a separate
> +

o Something's missing there?


diff -urN linux-2.5.59/Makefile linux-2.5.59-hal/Makefile
--- linux-2.5.59/Makefile	Wed Jan 22 12:25:58 2003
+++ linux-2.5.59-hal/Makefile	Wed Jan 22 22:36:00 2003
@@ -264,6 +264,18 @@
 CFLAGS		+= -fomit-frame-pointer
 endif
 
+ifdef CONFIG_X86_HAL
+# On x86, if compiling for the Hardware Abstraction Layer
+# (running Linux as a guest OS in a Virtual Machine),
+# we need to insert some asm macros which redefine
+# the behaviour of instructions which modify the
+# interrupt flag.  You are probably not configuring for
+# this mode.  For more info, read 'Documentation/x86-hal.txt'.
+# This needs to be the first include any module sees.
+CFLAGS		+= -include include/asm/if.h
+AFLAGS		+= -include include/asm/if.h
+endif
+
 #
 # INSTALL_PATH specifies where to place the updated kernel and system map
 # images.  Uncomment if you want to place them anywhere other than root.
@@ -409,6 +421,10 @@
 #	their vmlinux.lds.S file
 
 AFLAGS_vmlinux.lds.o += -P -C -U$(ARCH)
+
+ifdef CONFIG_X86_HAL
+AFLAGS_vmlinux.lds.o += -DNO_X86_HAL_INCLUDES
+endif
 
 arch/$(ARCH)/vmlinux.lds.s: %.s: %.S scripts FORCE
 	$(call if_changed_dep,as_s_S)

o These modifications should be done from arch/i386/Makefile instead, 
  since they're obviously i386-specific.

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Kevin Lawton]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

--- Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de> wrote:

> Three minor points:

OK, done.  Here's my #3 submission.  Some great
feedback from you guys.  Mods are down to:

  o Documentation/x86-hal.txt      # added file
  o include/asm-i386/if.h          # added file (only used for VM)
  o arch/i386/Kconfig              # added one menu entry
  o arch/i386/Makefile             # added one ifdef..endif
  o arch/i386/boot/Makefile        # added one ifdef..endif

-Kevin

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

[-- Attachment #2: linux-2.5.59-hal3.diffs --]
[-- Type: application/octet-stream, Size: 11867 bytes --]

diff -urN linux-2.5.59/Documentation/x86-hal.txt linux-2.5.59-hal/Documentation/x86-hal.txt
--- linux-2.5.59/Documentation/x86-hal.txt	Wed Dec 31 19:00:00 1969
+++ linux-2.5.59-hal/Documentation/x86-hal.txt	Thu Jan 23 01:07:23 2003
@@ -0,0 +1,114 @@
+x86 Hardware Abstraction Layer
+==============================
+
+Maintained by Kevin P. Lawton <kevinlawton2001@yahoo.com>
+Last updated: Wed Jan 22 17:05:05 EST 2003
+
+The goal of the x86 hardware abstraction layer is to provide
+a way to run the mainstream x86 Linux kernel as a guest OS, in
+a lightweight Virtual Machine (VM), provided by a new cut-down
+plex86 port.  For reference, see the section on plex86.
+
+The idea being, to have the ability to configure/compile x86 Linux
+"out-of-the-box", disabling lots of unnecessary host-oriented
+hardware support, and running it unpatched inside a special
+VM container.
+
+Because the VM understands that a VM'able guest OS is running,
+_many_ of the heavy x86 VM techniques are unnessary, and only
+the core set of IO functionality needs to be emulated; things
+like the interrupt controller, timers, straight text-mode
+VGA frame buffer, and other things which are very lightweight
+to emulate.  References to these devices can be easily monitored
+by a VM monitor, without modification to the Linux kernel.
+
+The functionality of heavy IO devices like disk/network, are
+best handled by efficient loadable kernel modules designed for
+Linux as a guest.  These modules can communicate a hardware
+abstraction layer protocol to the host OS outside the VM
+to handle the IO workload independently by the host OS,
+which is likely Linux (of course!).
+
+
+Why a Linux VM?
+===============
+
+  o Ability to have multiple Linux installations on one machine
+    at your disposal, with various software configuations.
+    This is great for developers, and call-in support centers
+    who need to have a matrix of OS/application versions
+    available.
+
+  o Security.  There are tons of applications here.  Firewalling
+    of certain applications, honey-pots, ...  I'll let the
+    security guys fill in this category.
+
+  o Provisioning of server resources.  Having the ability to
+    consolidate servers to optimize the use of each CPU.  And
+    to dynamically spin up servers on-demand.  Lots of
+    consoliation and load-balancing plays here.
+
+  o Ability to log into a specific/personal VM "context"
+    from across the Internet, but to have the VM centrally
+    located (and maintained) on servers.  The "context"
+    is the particular Linux install with all of the
+    user-specific files.
+
+
+What is plex86?
+===============
+
+Plex86 is an x86 virtual machine project.  Though it's a separate
+entity, it is currently a subdirectory of "bochs", an x86 PC
+emulation project which can be found on
+
+  http://bochs.sourceforge.net/
+
+Originally, the goals of plex86 were to run any guest OS
+inside the VM, which required some heavy trickery.  I
+completely gutted plex86, and now it is an incredibly
+small and lightweight x86 VM, meant to run code which
+is "VM friendly".  Or in other words, if you don't need to
+run non-Linux, you don't need 99% of the VM baggage.
+
+Plex86 is not ready yet for running Linux as a guest, but I do
+have it working in tandem with bochs to run Linux user-level
+code inside the VM.
+
+
+How much does it cost?
+======================
+
+Nothing, it's Open Source.  Linux is obviously a GPL'd program.
+Plex86 is an LGPL'd kernel module.
+
+
+What kind of modifications to the Linux kernel are needed?
+==========================================================
+
+The ideal answer would be none.  The goal is to run the
+actual x86 codebase, with the aim for this to be usable in
+enterprise-level settings.  Thus, it's much more appealing
+not to have modifications, but to leverage all the
+testing that the main codebase goes through.
+
+So far, there are just a couple x86 instructions which
+can be easily macro'ized to change their behaviour, relating
+to manipulation of the interrupt flag.  This is due to
+a deficiency in the handling of code running with Protected
+mode Virtual Interrupts (PVI).  Thus far, the code impact
+is one extra header file, and a few lines to conditionally
+include it!
+
+I am _really_ hoping these small mods make it into the main
+kernel base before Linux 2.6.0.  I believe there will be
+commercial thrust behind running Linux VMs, and would like
+to see the ability to compile kernel source included with
+the major Linux distros, as-is with no extra patches.
+
+For kernel modules which are developed to facilitate a
+Linux VM communicating HAL protocol to the host Linux,
+I have no religion.  They can be maintained wherever makes
+sense.
+
+-Kevin
diff -urN linux-2.5.59/arch/i386/Kconfig linux-2.5.59-hal/arch/i386/Kconfig
--- linux-2.5.59/arch/i386/Kconfig	Wed Jan 22 12:25:59 2003
+++ linux-2.5.59-hal/arch/i386/Kconfig	Wed Jan 22 23:41:11 2003
@@ -1661,3 +1661,20 @@
 	bool
 	depends on SMP
 	default y
+
+menu "Hardware Abstraction Layer"
+
+config X86_HAL
+	bool "Compile for HAL (experimental)"
+	depends on !HIGHMEM && !SMP && !M486 && !M386 && !X86_UP_APIC && !X86_UP_IOAPIC
+	help
+    Experimental: Say Y here _only_ if you are compiling Linux to run inside
+    an experimental Hardware Abstraction Layer.  This is only useful
+    for running Linux as a guest OS in a special virtual machine.
+    Say N here unless you absolutely know what this is for.  This
+    will break Linux running on a real machine for sure.  This option
+    has the following configuration constraints: Pentium or higher,
+    uniprocessor mode, no apic support.  For more info see
+    <file:Documentation/x86-hal.txt>.
+
+endmenu
diff -urN linux-2.5.59/arch/i386/Makefile linux-2.5.59-hal/arch/i386/Makefile
--- linux-2.5.59/arch/i386/Makefile	Wed Jan 22 12:25:59 2003
+++ linux-2.5.59-hal/arch/i386/Makefile	Thu Jan 23 01:14:14 2003
@@ -90,6 +90,19 @@
 CFLAGS += $(mflags-y)
 AFLAGS += $(mflags-y)
 
+ifdef CONFIG_X86_HAL
+# On x86, if compiling for the Hardware Abstraction Layer
+# (running Linux as a guest OS in a Virtual Machine),
+# we need to insert some asm macros which redefine
+# the behaviour of instructions which modify the
+# interrupt flag.  You are probably not configuring for
+# this mode.  For more info, read 'Documentation/x86-hal.txt'.
+# This needs to be the first include any module sees.
+CFLAGS          += -include include/asm/if.h
+AFLAGS          += -include include/asm/if.h
+AFLAGS_vmlinux.lds.o += -DNO_X86_HAL_INCLUDES
+endif
+
 boot := arch/i386/boot
 
 .PHONY: zImage bzImage compressed zlilo bzlilo zdisk bzdisk install \
diff -urN linux-2.5.59/arch/i386/boot/Makefile linux-2.5.59-hal/arch/i386/boot/Makefile
--- linux-2.5.59/arch/i386/boot/Makefile	Tue Jan 14 00:58:35 2003
+++ linux-2.5.59-hal/arch/i386/boot/Makefile	Wed Jan 22 22:52:40 2003
@@ -32,6 +32,10 @@
 
 host-progs	:= tools/build
 
+ifdef CONFIG_X86_HAL
+AFLAGS += -DNO_X86_HAL_INCLUDES
+endif
+
 # ---------------------------------------------------------------------------
 
 $(obj)/zImage:  IMAGE_OFFSET := 0x1000
diff -urN linux-2.5.59/include/asm-i386/if.h linux-2.5.59-hal/include/asm-i386/if.h
--- linux-2.5.59/include/asm-i386/if.h	Wed Dec 31 19:00:00 1969
+++ linux-2.5.59-hal/include/asm-i386/if.h	Wed Jan 22 22:35:02 2003
@@ -0,0 +1,157 @@
+#ifndef NO_X86_HAL_INCLUDES
+/*
+ *	Routines to manipulate the interrupt flag (EFLAGS.IF).  Abstracting
+ *	them, makes it easier to compile for a hardware abstraction layer (HAL).
+ *
+ *	(c) 2003 Kevin P. Lawton <kevinlawton2001@yahoo.com>
+ */
+
+#ifndef _LINUX_ASM_IF_H_
+#define _LINUX_ASM_IF_H_
+
+
+/* NOTE: This file is directly included via the "-include include/asm/if.h"
+ * option conditionally added to the compiler flags by the top Makefile when
+ * CONFIG_X86_HAL is defined.  None of the header files have been included
+ * at this point.
+ */
+
+/* For a HAL (Hardware Abstraction Layer) compile, the kernel is executed
+ * at PL=3 using PVI (Protected mode Virtual Interrupts), which are the
+ * analog to VME for v86 code.  For some reason, The Creators stopped short of
+ * implementing proper IF handling for PUSHF/POPF for PVI, but STI/CLI are
+ * fine.  So we have to complete the PVI semantics using the following
+ * sequences.
+ */
+
+/* Shield your eyes.  These macros make it possible to use the same
+ * code for asm or C inline asm, with all the quoting, comma, and
+ * newline issues.  Q1 is for lines with no commas, and Q2 is for lines
+ * with one comma.
+ */
+#ifdef __ASSEMBLY__
+#define Q1(s0)     s0
+#define Q2(s0, s1) s0, s1
+#else
+#define Q1(s0)     #s0 "\n\t"
+#define Q2(s0, s1) #s0 "," #s1 "\n\t"
+#endif
+
+
+#ifndef __ASSEMBLY__
+__asm__ (
+#endif
+
+  Q1(.macro  cli)
+  Q1(.byte 0xfa)     /* cli (native instruction works fine in PVI) */
+  Q1(.endm)
+
+  Q1(.macro  sti)
+  Q1(.byte 0xfb)     /* sti (native instruction works fine in PVI) */
+  Q1(.endm)
+
+#ifndef __ASSEMBLY__
+  );
+#endif
+
+
+
+/* PUSHFL:
+ * When execution is monitored using PVI (Protected mode Virtual Interrupts),
+ * we have to complete the PVI semantics of the PUSHFL instruction, as
+ * per behaviour of VME.
+ *
+ *                        b19           b9
+ * CPU   image of eflags: VIF           IF
+ *                         |
+ *                         +------------+
+ *                                      |
+ *                                      v
+ * Stack image of eflags: VIF           IF
+ *
+ * Notes: VIF on the stack image could be cleared, if it matters.
+ */
+
+#ifndef __ASSEMBLY__
+__asm__ (
+#endif
+
+  Q1(  .macro pushfl)
+  Q1(  .byte 0x9c)                /* (pushfl) Final eflags stack image. */
+  Q1(  .byte 0x9c)                /* (pushfl) For restoring arith flags. */
+  Q2(  testl $(1<<19), 4(%esp))   /* Was VIF bit set? */
+  Q1(  jz 69001f)
+  Q2(  orl   $(1<<9), 4(%esp))    /* Yes: set stack image of IF. */
+  Q1(  jmp 69002f)
+  Q1(69001:)                      /* Use the zip of Lyon France :^} */
+  Q2(  andl  $~(1<<9), 4(%esp))   /* No: clear stack image of IF. */
+  Q1(69002:)
+  Q1(  .byte 0x9d)                /* (popfl) Restore arithmetic flags. */
+  Q1(  .endm)
+
+  /* The user may use pushf with an implicit size.  Just expand that
+   * to the previous macro.
+   */
+  Q1(.macro pushf)
+  Q1(pushfl)
+  Q1(.endm)
+
+#ifndef __ASSEMBLY__
+  );
+#endif
+
+
+
+/* POPFL:
+ * When execution is monitored using PVI (Protected mode Virtual Interrupts),
+ * we have to complete the PVI semantics of the POPFL instruction, as
+ * per behaviour of VME.
+ *
+ *                        b19           b9
+ * Stack image of eflags: VIF           IF
+ *                                      |
+ *                         +------------+
+ *                         |
+ *                         v
+ * CPU   image of eflags: VIF           IF
+ *
+ * Notes: IF of the eflags register retains its previous value, which
+ *   should be 1 (when monitored down to PL3, the processor ignores this
+ *   bit in a POPF).
+ */
+
+#ifndef __ASSEMBLY__
+__asm__ (
+#endif
+
+  Q1(  .macro popfl)
+  Q2(  testl $(1<<9), 0(%esp))    /* Is IF set on stack image? */
+  Q1(  jz 69003f)
+  Q1(  .byte 0x9d)                /* (popfl) Yes: restore from stack and */
+  Q1(  sti)                       /* force VIF=1. */
+  Q1(  jmp 69004f)
+  Q1(69003:)
+  Q1(  .byte 0x9d)                /* (popfl) No: restore from stack and */
+  Q1(  cli)                       /* force VIF=0. */
+  Q1(69004:)
+  Q1(  .endm)
+
+  /* The user may use popf with an implicit size.  Just expand that
+   * to the previous macro.
+   */
+  Q1(.macro popf)
+  Q1(popfl)
+  Q1(.endm)
+
+#ifndef __ASSEMBLY__
+  );
+#endif
+
+/* Get rid of quoting macros - good housekeeping. */
+#undef Q1
+#undef Q2
+
+
+#endif  /* _LINUX_ASM_IF_H_ */
+
+#endif  /*  NO_X86_HAL_INCLUDES */

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Andrew Morton]

Kevin Lawton <kevinlawton2001@yahoo.com> wrote:
>
> --- Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de> wrote:
> 
> > Three minor points:
> 
> OK, done.  Here's my #3 submission.

Kinda cruel making you do all this work when Linus is unlikely to take the
patch anyway ;)

Thanks for the explanation - all is much clearer - it looks like very cool
technology.

- <asm/if.h> doesn't mean much to me.  Network interface, if anything.  How
  about <asm/asm-macros.h> ?

- It's quite conceivable that the infrastructure will be used for other
  forms of asm-mangling.  Those "Q2" things hurt like hell.  Is there no
  other way?

- application/octet-stream!

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Kevin Lawton]

--- Andrew Morton <akpm@digeo.com> wrote:

> Kinda cruel making you do all this work when Linus is unlikely to take the
> patch anyway ;)

If there's a misunderstanding of the potential here, of the commercial
potential, or the user-demand for these patches (which now touch
absolutely no existing *.{c,S,h} files, then I'm willing to communicate
those things to whomever needs it.

This is not a toy.  The goal is not to continue modifying the kernel
or make anybody's life hard.  The contrary is true - I don't want
any modifications.  These are extremely simple patches to fix one
pair of broken instructions in PVI mode.

Coming from an x86 company, I'm betting Linus will get this
in a nano-second.  Let's not speak for him.


-Kevin

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Pavel Machek]

Hi!

> OK, here's my re-submit of patches, after some great
> clean-up/simplification ideas from Andrew Morton and Andi Kleen.

Please try to inline the patches, it makes it easier to comment.

How is plex86-aware-linux running under plex86 different from user
mode linux? Do you think you can make it faster?
								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Kevin Lawton]

--- Pavel Machek <pavel@ucw.cz> wrote:

> How is plex86-aware-linux running under plex86 different from user
> mode linux?

With plex86, the goal is to run the stock x86 port.  Plex86 is also
x86-specific.

> Do you think you can make it faster?

To get any level of security with UML, you need to use "jailed mode"
in which performance takes a big beating.  To fix this, you need
patches to Linux as a host, to make it offer a better environment
for running UML guests.  From a commercial perspective, then you have
a patched Linux host + totally different port of a Linux guest.
>From a fun perspective, I think UML is fantastic achievement.

What I'm aiming for is a stock Linux host and a stock Linux guest,
the small mods to macroize PUSHF/POPF being a minor concession
to accomodate a broken PVI support in x86.


-Kevin

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Lars Marowsky-Bree]

On 2003-01-24T09:14:15,
   Kevin Lawton <kevinlawton2001@yahoo.com> said:

> To get any level of security with UML, you need to use "jailed mode"
> in which performance takes a big beating.  To fix this, you need
> patches to Linux as a host, to make it offer a better environment
> for running UML guests.  From a commercial perspective, then you have
> a patched Linux host + totally different port of a Linux guest.

That commercial perspective is then completely misguided.

All alternatives I have seen to UML (plex, vmware, UMLinux) suck IMHO. They
are inherently much more platform specific than UML. The necessary
modifications on the host for UML ska mode are minimal and I think besides
bashing out whether it should be a syscall, proc file or whatever, everybody
seems pretty much set on integrating them into the kernel.


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
Principal Squirrel 
SuSE Labs - Research & Development, SuSE Linux AG
  
"If anything can go wrong, it will." "Chance favors the prepared (mind)."
  -- Capt. Edward A. Murphy            -- Louis Pasteur

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[David Wagner]

Lars Marowsky-Bree  wrote:
>All alternatives I have seen to UML (plex, vmware, UMLinux) suck IMHO.

It seems plausible to expect that it might be easier to verify security
in plex86-based approaches than it is to verify security in UML.

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Jan Hudec]

On Sat, Jan 25, 2003 at 01:46:56AM +0000, David Wagner wrote:
> Lars Marowsky-Bree  wrote:
> >All alternatives I have seen to UML (plex, vmware, UMLinux) suck IMHO.
> 
> It seems plausible to expect that it might be easier to verify security
> in plex86-based approaches than it is to verify security in UML.

IIRC plex86 requires quite large module on the host. And I am not sure
it's does not have any privilegies. Umlinux requires no or very minimal
(thus easy to check for insecurities) patch to kernel and does not need
any privilegies (except the helper that sets up networking, but that's
pretty minimalistic too). If you properly chroot the umlinux process,
it's very secure (the skas mode will only work in chroot once it's made
to use syscall).

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Pavel Machek]

Hi!

> >All alternatives I have seen to UML (plex, vmware, UMLinux) suck IMHO.
> 
> It seems plausible to expect that it might be easier to verify security
> in plex86-based approaches than it is to verify security in UML.

As plex86 uses pretty obscure tricks (like PVI -- is it even
documented in official Intel docs?), I doubt it is going to be easier
to verify.
								Pavel

-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Pavel Machek]

Hi!

> > To get any level of security with UML, you need to use "jailed mode"
> > in which performance takes a big beating.  To fix this, you need
> > patches to Linux as a host, to make it offer a better environment
> > for running UML guests.  From a commercial perspective, then you have
> > a patched Linux host + totally different port of a Linux guest.
> 
> That commercial perspective is then completely misguided.
> 
> All alternatives I have seen to UML (plex, vmware, UMLinux) suck
 > IMHO. They

I know UML, but what is UMLinux?
								Pavel

-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Lars Marowsky-Bree]

On 2003-01-26T21:00:21,
   Pavel Machek <pavel@suse.cz> said:

> I know UML, but what is UMLinux?

Google, 3 seconds: http://www.umlinux.de/ :-)


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
Principal Squirrel 
SuSE Labs - Research & Development, SuSE Linux AG
  
"If anything can go wrong, it will." "Chance favors the prepared (mind)."
  -- Capt. Edward A. Murphy            -- Louis Pasteur

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Nuno Silva]

Hello!

Why don't you take the route that Jeff Dike did with UML's skas mode?

List the patches in your site and release plex86-v2 that requires this 
host patches to run.

If the results are really good lots of people will use it and you'll end 
up with a number of people asking in lkml "why is the plex86-v2 patch 
not available in Linus' tree?" ;)

Regards,
Nuno Silva

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Kevin Lawton]

OK, rev#4 (and hopefully final).  I only renamed a file,
as per suggestion of Andrew Morton.  Haven't seen anything
else worth changing.

Quick recap of the mods involved:

  o Documentation/x86-hal.txt      # added file
  o include/asm-i386/eflags_if.h   # added file (only used for VM)
  o arch/i386/Kconfig              # added one menu entry
  o arch/i386/Makefile             # added one ifdef..endif
  o arch/i386/boot/Makefile        # added one ifdef..endif

Diffs are available at:

  http://bochs.sourceforge.net/tmp/linux-2.5.59-hal4

The file 'Documentation/x86-hal.txt' explains the rationale for
these mods and my case for them going into the kernel before 2.6.

No *.{c,h,S} files are modified.

-Kevin

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Kevin Lawton]

[-- Attachment #1: Type: text/plain, Size: 946 bytes --]

Hello all,

I'm working on running Linux as a guest OS inside a
lightweight cut-down plex86 environment.  My goal is to
run a stock Linux kernel, which can be slimmed down to
the essentials via kernel configuration, since a guest
OS doesn't need to drive much hardware.

For this, there's a few critical but simple diffs to
macro'ize the use of the PUSHF and POPF instructions,
due to broken semantics of running stuff using
PVI (protected mode virtual interrupts).  The rest of
the stuff I believe can be monitored effectively by
the VM monitor.

Would you please consider integrating these diffs before 2.6?
There's only one new header file, and macro substitution for
a few cases where these instructions are used.  For a normal
compile, there are zero logic changes.  Just 1:1 macros.

Thanks much,
-Kevin Lawton

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

[-- Attachment #2: linux-2.5.59-hal.diffs --]
[-- Type: application/octet-stream, Size: 14344 bytes --]

diff -urN linux-2.5.59/arch/i386/Kconfig linux-2.5.59-hal/arch/i386/Kconfig
--- linux-2.5.59/arch/i386/Kconfig	Wed Jan 22 12:25:59 2003
+++ linux-2.5.59-hal/arch/i386/Kconfig	Tue Jan 21 17:23:41 2003
@@ -1661,3 +1661,18 @@
 	bool
 	depends on SMP
 	default y
+
+menu "Hardware Abstraction Layer"
+
+config X86_HAL
+	bool "Compile for HAL (experimental)"
+	depends on !HIGHMEM && !SMP && !M486 && !M386 && !X86_UP_APIC && !X86_UP_IOAPIC
+	help
+    Say Y here _only_ if you are compiling Linux to run inside an
+    experimental Hardware Abstraction Layer.  Say N here unless
+    you absolutely know what this is for.  This will break Linux
+    running on a real machine for sure.  This option has the
+    following configuration constraints: Pentium or higher,
+    uniprocessor mode, no apic support.
+
+endmenu
diff -urN linux-2.5.59/arch/i386/kernel/acpi_wakeup.S linux-2.5.59-hal/arch/i386/kernel/acpi_wakeup.S
--- linux-2.5.59/arch/i386/kernel/acpi_wakeup.S	Tue Jan 14 00:58:23 2003
+++ linux-2.5.59-hal/arch/i386/kernel/acpi_wakeup.S	Tue Jan 21 18:35:48 2003
@@ -2,6 +2,7 @@
 #include <linux/linkage.h>
 #include <asm/segment.h>
 #include <asm/page.h>
+#include <asm/if.h>
 
 #
 # wakeup_code runs in real mode, and at unknown address (determined at run-time).
@@ -35,7 +36,7 @@
 	movw	$0x0e00 + 'S', %fs:(0x12)
 
 	pushl	$0						# Kill any dangerous flags
-	popfl
+	POPFL
 
 	movl	real_magic - wakeup_code, %eax
 	cmpl	$0x12345678, %eax
@@ -283,7 +284,7 @@
 	movl %ebp, saved_context_ebp
 	movl %esi, saved_context_esi
 	movl %edi, saved_context_edi
-	pushfl ; popl saved_context_eflags
+	PUSHFL ; popl saved_context_eflags
 
 	movl $.L1432,saved_eip
 	movl %esp,saved_esp
@@ -309,7 +310,7 @@
 	movl saved_context_esi, %esi
 	movl saved_context_edi, %edi
 	call restore_processor_state
-	pushl saved_context_eflags ; popfl
+	pushl saved_context_eflags ; POPFL
 	ret
 
 ALIGN
diff -urN linux-2.5.59/arch/i386/kernel/cpu/common.c linux-2.5.59-hal/arch/i386/kernel/cpu/common.c
--- linux-2.5.59/arch/i386/kernel/cpu/common.c	Tue Jan 14 00:58:04 2003
+++ linux-2.5.59-hal/arch/i386/kernel/cpu/common.c	Wed Jan 22 02:01:26 2003
@@ -7,6 +7,7 @@
 #include <asm/msr.h>
 #include <asm/io.h>
 #include <asm/mmu_context.h>
+#include <asm/if.h>
 
 #include "cpu.h"
 
@@ -170,16 +171,16 @@
 {
 	u32 f1, f2;
 
-	asm("pushfl\n\t"
-	    "pushfl\n\t"
+	asm( PUSHFL
+	     PUSHFL
 	    "popl %0\n\t"
 	    "movl %0,%1\n\t"
 	    "xorl %2,%0\n\t"
 	    "pushl %0\n\t"
-	    "popfl\n\t"
-	    "pushfl\n\t"
+	     POPFL
+	     PUSHFL
 	    "popl %0\n\t"
-	    "popfl\n\t"
+	     POPFL
 	    : "=&r" (f1), "=&r" (f2)
 	    : "ir" (flag));
 
@@ -473,7 +474,7 @@
 	/*
 	 * Delete NT
 	 */
-	__asm__("pushfl ; andl $0xffffbfff,(%esp) ; popfl");
+	__asm__(PUSHFL " ; andl $0xffffbfff,(%%esp) ; " POPFL : );
 
 	/*
 	 * Set up and load the per-CPU TSS and LDT
diff -urN linux-2.5.59/arch/i386/kernel/entry.S linux-2.5.59-hal/arch/i386/kernel/entry.S
--- linux-2.5.59/arch/i386/kernel/entry.S	Wed Jan 22 12:25:59 2003
+++ linux-2.5.59-hal/arch/i386/kernel/entry.S	Tue Jan 21 18:36:16 2003
@@ -48,6 +48,7 @@
 #include <asm/segment.h>
 #include <asm/smp.h>
 #include <asm/page.h>
+#include <asm/if.h>
 #include "irq_vectors.h"
 
 EBX		= 0x00
@@ -141,7 +142,7 @@
 
 
 ENTRY(lcall7)
-	pushfl			# We get a different stack layout with call
+	PUSHFL			# We get a different stack layout with call
 				# gates, which has to be cleaned up later..
 	pushl %eax
 	SAVE_ALL
@@ -163,7 +164,7 @@
 	jmp resume_userspace
 
 ENTRY(lcall27)
-	pushfl			# We get a different stack layout with call
+	PUSHFL			# We get a different stack layout with call
 				# gates, which has to be cleaned up later..
 	pushl %eax
 	SAVE_ALL
@@ -233,7 +234,7 @@
 	sti
 	pushl $(__USER_DS)
 	pushl %ebp
-	pushfl
+	PUSHFL
 	pushl $(__USER_CS)
 	pushl $SYSENTER_RETURN
 
diff -urN linux-2.5.59/arch/i386/kernel/head.S linux-2.5.59-hal/arch/i386/kernel/head.S
--- linux-2.5.59/arch/i386/kernel/head.S	Tue Jan 14 00:58:06 2003
+++ linux-2.5.59-hal/arch/i386/kernel/head.S	Tue Jan 21 18:35:07 2003
@@ -16,6 +16,7 @@
 #include <asm/pgtable.h>
 #include <asm/desc.h>
 #include <asm/cache.h>
+#include <asm/if.h>
 
 #define OLD_CL_MAGIC_ADDR	0x90020
 #define OLD_CL_MAGIC		0xA33F
@@ -111,7 +112,7 @@
 	orw  %bx,%bx
 	jz  1f				/* Initial CPU cleans BSS */
 	pushl $0
-	popfl
+	POPFL
 	jmp checkCPUtype
 1:
 #endif CONFIG_SMP
@@ -138,7 +139,7 @@
  * XXX - best to initialize before switching to protected mode.
  */
 	pushl $0
-	popfl
+	POPFL
 /*
  * Copy bootup parameters out of the way. First 2kB of
  * _empty_zero_page is for boot parameters, second 2kB
@@ -180,17 +181,17 @@
  */
 
 	movb $3,X86		# at least 386
-	pushfl			# push EFLAGS
+	PUSHFL			# push EFLAGS
 	popl %eax		# get EFLAGS
 	movl %eax,%ecx		# save original EFLAGS
 	xorl $0x240000,%eax	# flip AC and ID bits in EFLAGS
 	pushl %eax		# copy to EFLAGS
-	popfl			# set EFLAGS
-	pushfl			# get new EFLAGS
+	POPFL			# set EFLAGS
+	PUSHFL			# get new EFLAGS
 	popl %eax		# put it in eax
 	xorl %ecx,%eax		# change in flags
 	pushl %ecx		# restore original EFLAGS
-	popfl
+	POPFL
 	testl $0x40000,%eax	# check if AC bit changed
 	je is386
 
diff -urN linux-2.5.59/arch/i386/kernel/suspend_asm.S linux-2.5.59-hal/arch/i386/kernel/suspend_asm.S
--- linux-2.5.59/arch/i386/kernel/suspend_asm.S	Tue Jan 14 00:58:33 2003
+++ linux-2.5.59-hal/arch/i386/kernel/suspend_asm.S	Tue Jan 21 18:36:31 2003
@@ -5,6 +5,7 @@
 #include <linux/linkage.h>
 #include <asm/segment.h>
 #include <asm/page.h>
+#include <asm/if.h>
 
 ENTRY(do_magic)
 	pushl %ebx
@@ -21,7 +22,7 @@
 	movl %ebp, saved_context_ebp
 	movl %esi, saved_context_esi
 	movl %edi, saved_context_edi
-	pushfl ; popl saved_context_eflags
+	PUSHFL ; popl saved_context_eflags
 
 	call do_magic_suspend_2
 	jmp .L1449
@@ -77,7 +78,7 @@
 	movl saved_context_esi, %esi
 	movl saved_context_edi, %edi
 	call restore_processor_state
-	pushl saved_context_eflags ; popfl
+	pushl saved_context_eflags ; POPFL
 	call do_magic_resume_2
 .L1449:
 	popl %ebx
@@ -89,4 +90,4 @@
 loop2:
        .quad 0
        .previous
-	
\ No newline at end of file
+	
diff -urN linux-2.5.59/drivers/hotplug/cpqphp_nvram.c linux-2.5.59-hal/drivers/hotplug/cpqphp_nvram.c
--- linux-2.5.59/drivers/hotplug/cpqphp_nvram.c	Tue Jan 14 00:59:15 2003
+++ linux-2.5.59-hal/drivers/hotplug/cpqphp_nvram.c	Tue Jan 21 18:25:57 2003
@@ -37,6 +37,7 @@
 #include <linux/pci.h>
 #include <linux/init.h>
 #include <asm/uaccess.h>
+#include <asm/if.h>
 #include "cpqphp.h"
 #include "cpqphp_nvram.h"
 
@@ -179,7 +180,7 @@
 	__asm__ (
 		"xorl   %%ebx,%%ebx\n" \
 		"xorl    %%edx,%%edx\n" \
-		"pushf\n" \
+		 PUSHFL   \
 		"push %%cs\n" \
 		"cli\n" \
 		"call *%6\n"
diff -urN linux-2.5.59/drivers/pnp/pnpbios/core.c linux-2.5.59-hal/drivers/pnp/pnpbios/core.c
--- linux-2.5.59/drivers/pnp/pnpbios/core.c	Tue Jan 14 00:58:04 2003
+++ linux-2.5.59-hal/drivers/pnp/pnpbios/core.c	Tue Jan 21 18:31:26 2003
@@ -54,6 +54,7 @@
 #include <linux/spinlock.h>
 #include <asm/system.h>
 #include <asm/byteorder.h>
+#include <asm/if.h>
 
 
 /*
@@ -185,11 +186,11 @@
 		"pushl %%es\n\t"
 		"pushl %%fs\n\t"
 		"pushl %%gs\n\t"
-		"pushfl\n\t"
+		 PUSHFL
 		"movl %%esp, pnp_bios_fault_esp\n\t"
 		"movl $1f, pnp_bios_fault_eip\n\t"
 		"lcall %5,%6\n\t"
-		"1:popfl\n\t"
+		"1:" POPFL
 		"popl %%gs\n\t"
 		"popl %%fs\n\t"
 		"popl %%es\n\t"
diff -urN linux-2.5.59/include/asm-i386/if.h linux-2.5.59-hal/include/asm-i386/if.h
--- linux-2.5.59/include/asm-i386/if.h	Wed Dec 31 19:00:00 1969
+++ linux-2.5.59-hal/include/asm-i386/if.h	Wed Jan 22 11:26:59 2003
@@ -0,0 +1,139 @@
+/*
+ *	Routines to manipulate the interrupt flag (EFLAGS.IF).  Abstracting
+ *	them, makes it easier to compile for a hardware abstraction layer (HAL).
+ *
+ *	(c) 2003 Kevin P. Lawton <kevinlawton2001@yahoo.com>
+ */
+
+#ifndef _LINUX_ASM_IF_H_
+#define _LINUX_ASM_IF_H_
+
+
+#ifndef CONFIG_X86_HAL
+
+/* For a standard compile, just use the native instructions. */
+
+#ifdef __ASSEMBLY__           /* For *.S assembly. */
+#define STI    sti
+#define CLI    cli
+#define PUSHFL pushfl
+#define POPFL  popfl
+#else                         /* For *.C assembly. */
+#define STI    "sti    \n\t"
+#define CLI    "cli    \n\t"
+#define PUSHFL "pushfl \n\t"
+#define POPFL  "popfl  \n\t"
+#endif
+
+
+#else   /* CONFIG_X86_HAL */
+
+/* For a HAL (Hardware Abstraction Layer) compile, the kernel is executed
+ * at PL=3 using PVI (Protected mode Virtual Interrupts), which are the
+ * analog to VME for v86 code.  For some reason, The Creators stopped short of
+ * implementing proper IF handling for PUSHF/POPF for PVI, but STI/CLI are
+ * fine.  So we have to complete the PVI semantics using the following
+ * sequences.
+ */
+
+/* cli/sti both work in PVI */
+#ifdef __ASSEMBLY__           /* For *.S assembly. */
+#define STI    sti
+#define CLI    cli
+#else                         /* For *.C assembly. */
+#define STI    "sti    \n\t"
+#define CLI    "cli    \n\t"
+#endif
+
+
+/* PUSHFL:
+ * When execution is monitored using PVI (Protected mode Virtual Interrupts),
+ * we have to complete the PVI semantics of the PUSHFL instruction, as
+ * per behaviour of VME.
+ *
+ *                        b19           b9
+ * CPU   image of eflags: VIF           IF
+ *                         |
+ *                         +------------+
+ *                                      |
+ *                                      v
+ * Stack image of eflags: VIF           IF
+ *
+ * Notes: VIF on the stack image could be cleared, if it matters.
+ */
+
+#ifdef __ASSEMBLY__           /* For *.S assembly. */
+#define PUSHFL \
+   pushfl                   ; \
+   pushfl                   ; \
+   testl $(1<<19), 4(%esp)  ; \
+   jz 69001f                ; \
+   orl   $(1<<9), 4(%esp)   ; \
+   jmp 69002f               ; \
+   69001:                   ; \
+   andl  $~(1<<9), 4(%esp)  ; \
+   69002:                   ; \
+   popfl
+#else                         /* For *.C assembly. */
+#define PUSHFL \
+  "pushfl                     \n\t" /* Final eflags stack image. */ \
+  "pushfl                     \n\t" /* For restoring arithmetic flags. */ \
+  "testl $(1<<19), 4(%%esp)   \n\t" /* Was VIF bit set? */ \
+  "jz 69001f                  \n\t" \
+  "orl   $(1<<9), 4(%%esp)    \n\t" /* Yes: set stack image of IF. */ \
+  "jmp 69002f                 \n\t" \
+  "69001:                     \n\t" /* Use the zip of Lyon France :^) */ \
+  "andl  $~(1<<9), 4(%%esp)   \n\t" /* No: clear stack image of IF. */ \
+  "69002:                     \n\t" \
+  "popfl                      \n\t" /* Restore arithmetic flags. */
+#endif
+
+
+
+/* POPFL:
+ * When execution is monitored using PVI (Protected mode Virtual Interrupts),
+ * we have to complete the PVI semantics of the POPFL instruction, as
+ * per behaviour of VME.
+ *
+ *                        b19           b9
+ * Stack image of eflags: VIF           IF
+ *                                      |
+ *                         +------------+
+ *                         |
+ *                         v
+ * CPU   image of eflags: VIF           IF
+ *
+ * Notes: IF of the eflags register retains its previous value, which
+ *   should be 1 (when monitored down to PL3, the processor ignores this
+ *   bit in a POPF).
+ */
+
+#ifdef __ASSEMBLY__           /* For *.S assembly. */
+#define POPFL \
+   testl $(1<<9), 0(%esp)  ; \
+   jz 69003f               ; \
+   popfl                   ; \
+   sti                     ; \
+   jmp 69004f              ; \
+   69003:                  ; \
+   popfl                   ; \
+   cli                     ; \
+   69004:                
+#else                         /* For *.C assembly. */
+#define POPFL \
+  "testl $(1<<9), 0(%%esp)    \n\t" /* Is IF set on stack image? */ \
+  "jz 69003f                  \n\t" \
+  "popfl                      \n\t" /* Yes: restore from stack and */ \
+  "sti                        \n\t" /* force VIF=1. */ \
+  "jmp 69004f                 \n\t" \
+  "69003:                     \n\t" \
+  "popfl                      \n\t" /* No: restore from stack and */ \
+  "cli                        \n\t" /* force VIF=0. */ \
+  "69004:                     \n\t"
+#endif
+
+
+#endif  /* CONFIG_X86_HAL */
+
+
+#endif  /* _LINUX_ASM_IF_H_ */
diff -urN linux-2.5.59/include/asm-i386/system.h linux-2.5.59-hal/include/asm-i386/system.h
--- linux-2.5.59/include/asm-i386/system.h	Tue Jan 14 00:58:03 2003
+++ linux-2.5.59-hal/include/asm-i386/system.h	Tue Jan 21 18:34:08 2003
@@ -5,6 +5,7 @@
 #include <linux/kernel.h>
 #include <asm/segment.h>
 #include <linux/bitops.h> /* for LOCK_PREFIX */
+#include <asm/if.h>
 
 #ifdef __KERNEL__
 
@@ -12,7 +13,7 @@
 extern void FASTCALL(__switch_to(struct task_struct *prev, struct task_struct *next));
 
 #define switch_to(prev,next,last) do {					\
-	asm volatile("pushfl\n\t"					\
+	asm volatile(PUSHFL      					\
 		     "pushl %%esi\n\t"					\
 		     "pushl %%edi\n\t"					\
 		     "pushl %%ebp\n\t"					\
@@ -25,7 +26,7 @@
 		     "popl %%ebp\n\t"					\
 		     "popl %%edi\n\t"					\
 		     "popl %%esi\n\t"					\
-		     "popfl\n\t"					\
+		     POPFL      					\
 		     :"=m" (prev->thread.esp),"=m" (prev->thread.eip)	\
 		     :"m" (next->thread.esp),"m" (next->thread.eip),	\
 		      "a" (prev), "d" (next));				\
@@ -380,8 +381,8 @@
 #define set_wmb(var, value) do { var = value; wmb(); } while (0)
 
 /* interrupt control.. */
-#define local_save_flags(x)	__asm__ __volatile__("pushfl ; popl %0":"=g" (x): /* no input */)
-#define local_irq_restore(x) 	__asm__ __volatile__("pushl %0 ; popfl": /* no output */ :"g" (x):"memory", "cc")
+#define local_save_flags(x)	__asm__ __volatile__(PUSHFL " ; popl %0":"=g" (x): /* no input */)
+#define local_irq_restore(x) 	__asm__ __volatile__("pushl %0 ; " POPFL : /* no output */ :"g" (x):"memory", "cc")
 #define local_irq_disable() 	__asm__ __volatile__("cli": : :"memory")
 #define local_irq_enable()	__asm__ __volatile__("sti": : :"memory")
 /* used in the idle loop; sti takes one instruction cycle to complete */
@@ -395,7 +396,7 @@
 })
 
 /* For spinlocks etc */
-#define local_irq_save(x)	__asm__ __volatile__("pushfl ; popl %0 ; cli":"=g" (x): /* no input */ :"memory")
+#define local_irq_save(x)	__asm__ __volatile__(PUSHFL " ; popl %0 ; cli":"=g" (x): /* no input */ :"memory")
 
 /*
  * disable hlt during certain critical i/o operations

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Andrew Morton]

Kevin Lawton <kevinlawton2001@yahoo.com> wrote:
>
> Hello all,
> 
> I'm working on running Linux as a guest OS inside a
> lightweight cut-down plex86 environment.  My goal is to
> run a stock Linux kernel, which can be slimmed down to
> the essentials via kernel configuration, since a guest
> OS doesn't need to drive much hardware.
> 
> For this, there's a few critical but simple diffs to
> macro'ize the use of the PUSHF and POPF instructions,
> due to broken semantics of running stuff using
> PVI (protected mode virtual interrupts).  The rest of
> the stuff I believe can be monitored effectively by
> the VM monitor.
> 
> Would you please consider integrating these diffs before 2.6?
> There's only one new header file, and macro substitution for
> a few cases where these instructions are used.  For a normal
> compile, there are zero logic changes.  Just 1:1 macros.

I'm wondering if this can this be done a lot more simply with assembler
macros.

The below example generates the right code.  It's then just a matter of
getting the redefined pushfl and popfl macros into kernel-wide scope. 
Possibly an explicit `-include' in the makefile system.


asm("
	.macro	popfl
	testl	$(1<<9), 0(%esp)
	jz	69003f
	.byte	0x9d		# popfl
	sti
	jmp	69004f
69003:
	.byte	0x9d		# popfl
	cli
69004:                
	.endm
");

foo()
{
	asm("popfl\n");
}

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Kevin Lawton]

Humm, that's a good idea.  I already made the mods
to files to add an #include <asm/if.h>.  That would
be a logical place to stick such macros.  I will
check this out and re-submit the patches if it's
workable.

Maybe this was what Andi meant too.  Originally thought
he meant a script file wrapper for gcc.

Will write back soon,
-Kevin

--- Andrew Morton <akpm@digeo.com> wrote:

> I'm wondering if this can this be done a lot more simply with assembler
> macros.
> 
> The below example generates the right code.  It's then just a matter of
> getting the redefined pushfl and popfl macros into kernel-wide scope. 
> Possibly an explicit `-include' in the makefile system.
> 
> 
> asm("
> 	.macro	popfl
> 	testl	$(1<<9), 0(%esp)
> 	jz	69003f
> 	.byte	0x9d		# popfl
> 	sti
> 	jmp	69004f
> 69003:
> 	.byte	0x9d		# popfl
> 	cli
> 69004:                
> 	.endm
> ");
> 
> foo()
> {
> 	asm("popfl\n");
> }
> 


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Andrew Morton]

Kevin Lawton <kevinlawton2001@yahoo.com> wrote:
>
> Humm, that's a good idea.  I already made the mods
> to files to add an #include <asm/if.h>.  That would
> be a logical place to stick such macros.

<asm/if.h> is a fine place to put the macros.

However, open-coding

	#include <asm/if.h>

in the places which are known to use pushfl/popfl is fragile.  Because
someone could later do something odd which results in the generation of an
unmassaged pushfl/popfl.

You need a magic bullet.  Which is why I suggest including if.h via the build
system - making it truly global.

__ASSEMBLY__ and __KERNEL__ are provided via the build system as well, and
are in scope during that first inclusion.  So it _should_ work....

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Kai Germaschewski]

On Wed, 22 Jan 2003, Andrew Morton wrote:

> 	#include <asm/if.h>
> 
> in the places which are known to use pushfl/popfl is fragile.  Because
> someone could later do something odd which results in the generation of an
> unmassaged pushfl/popfl.
> 
> You need a magic bullet.  Which is why I suggest including if.h via the build
> system - making it truly global.
> 
> __ASSEMBLY__ and __KERNEL__ are provided via the build system as well, and
> are in scope during that first inclusion.  So it _should_ work....

Let me just mention "gcc -include <file>". I suppose that's what you were 
saying, anyway.

--Kai

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Ingo Oeser]

On Wed, Jan 22, 2003 at 10:23:41AM -0800, Kevin Lawton wrote:
> For this, there's a few critical but simple diffs to
> macro'ize the use of the PUSHF and POPF instructions,
> due to broken semantics of running stuff using
> PVI (protected mode virtual interrupts).  The rest of
> the stuff I believe can be monitored effectively by
> the VM monitor.

Yes, what you do is nice, but generates much code. What about
this for pushfl:

pushfl
push %eax
pushfl
pop %eax
orb $(1<<1),%ah  /* same as orl $(1<<9),%eax */
testl $(1<<19),%eax
jnz 69001f
andb $~(1<<1),%ah /* same as andl $~(1<<9),%eax */
69001:
mov %eax,4(%esp)
pop %eax


? This saves 6 bytes, which is a 20% code reduction ;-)

Regards

Ingo Oeser
-- 
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Jamie Lokier]

Ingo Oeser wrote:
> Yes, what you do is nice, but generates much code. What about
> this for pushfl:
> [11 lines of asm]

What about:

	.macro	pushfl
	call __pushfl
	.endm

	.macro  popfl
	call __popfl
	.endm

There, nice and small.

-- Jamie

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Kevin Lawton]

--- Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de> wrote:

> Yes, what you do is nice, but generates much code. What about
> this for pushfl:

Your code snipped is 10% slower.  I'm not sure if it's the extra
stack activity or the 8bit user of registers (which can
pose a hazard to the execution stream on some processors).
I'm gunning for high performance.

-Kevin

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Pavel Machek]

Hi!

> I'm working on running Linux as a guest OS inside a
> lightweight cut-down plex86 environment.  My goal is to
> run a stock Linux kernel, which can be slimmed down to
> the essentials via kernel configuration, since a guest
> OS doesn't need to drive much hardware.

Can you explain a bit more about plex86? I thought plex86 aims to be
complete machine emulation, capable of running winNT (for example). I
don't think M$ will accept such a patch from you...

Or will it only increase performance when running under plex86?

								Pavel

-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Kevin Lawton]

--- Pavel Machek <pavel@ucw.cz> wrote:

> Can you explain a bit more about plex86? I thought plex86 aims to be
> complete machine emulation, capable of running winNT (for example). I
> don't think M$ will accept such a patch from you...

I gutted the old plex86 code, eliminated all the fancy stuff
and it now does nothing except provide a VM container to
run user-privilege code only.  X86 is reasonably VM'able
at user priviliege, but not so at kernel privilege.

Plex86 is a kernel module which runs on the host OS.  It
provides a separate set of page tables, segment registers
and other stuff so that there is no interference with the
host structures, nor dependence on them whatsover.

The thrust behind these simple mods is to be able to "push"
Linux kernel code (when running as a guest OS) down to user
level.  In this case, it can also be run in what is now
an extremely light-weight VM.  To do this, proper maintenance
of the interrupt flag (x86) is necessary, since behaviour of
this flag in the eflags register is different at user-level.
The x86 architecture provides a mechanism for this, called PVI
(protected mode virtual interrupts), although the logic for
this was not carried over to 2 instructions (PUSHF/POPF).
Thus my patches...

Other than that, plex86 "shadows" the guest page tables and
discovers the guest page tables on-demand.  So nothing special
needs to be done.  Access to system registers trap from user code,
so the VM monitor can handle those properly.

About 99% of the work of a full x86 VM is on handling less
than 1% of the cases.  So the new plex86 angle is, forget doing
all the fancy work for 1%.  If you're running a VM friendly OS
(like Linux with my small patches), you end up with a potentially high
performance and Open Source VM, with very little work.

As well, plex86 can bolt on to bochs for accelerating user code,
reverting back to bochs for emulation of kernel code - perhaps
good for running non-Linux, and for debugging Linux kernels.

But for the normal case of running Linux VMs, plex86 will be a standalone.
Because the non-essential IO stuff can be configured out of Linux,
and the remaining essential IO can be monitored very lightweight style
in plex86 - even right in the VM monitor for high performance.

-Kevin

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]

On Fri, 24 Jan 2003 08:52:46 PST, Kevin Lawton said:

> About 99% of the work of a full x86 VM is on handling less
> than 1% of the cases.  So the new plex86 angle is, forget doing
> all the fancy work for 1%.  If you're running a VM friendly OS
> (like Linux with my small patches), you end up with a potentially high
> performance and Open Source VM, with very little work.

One of the first implementations of VM was by IBM, called CP/67.  It
eventually evolved into VM/370 and its follow-ons.

The initial design reason for CP/67 was to allow 2 or more MVS development
teams to share a system for testing, so the other team could keep working
while the first team debugged a system crash with tools better than the
lights-n-switches at the console.

It turns out that the 99% of the work to cover the 1% of the cases is really
important.  The usual reason for doing VM is to isolate images from each other
- and if you don't cover that last 1%, a programming error in one of the images
can nuke your supervisor code into oblivion.  It may be a "VM friendly OS like
Linux", but it can still oops in strange ways. For starters, what happens
if you run a Linux *without* your patches under plex86? ;)

Now if you think about it, and not covering the 1% case is deemed acceptable,
that's OK too.  But it's something that needs to be considered.
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Kevin Lawton]

--- Valdis.Kletnieks@vt.edu wrote:

> It turns out that the 99% of the work to cover the 1% of the cases is really
> important.  The usual reason for doing VM is to isolate images from each
> other

Plex86 can 100% isolate guests from each other.  What I'm saying
is, it takes 99% of the work to do a full x86 VM which doesn't
need those 2 macros for PUSHF/POPF.  (my oversimplified, but
yet useful explanation of the state of affairs)

You have to do a lot of work to "get under the hood" of an
OS, to fix up a few cases where if you let them run native,
they'll get the wrong information or make the wrong thing
happen.  Not to the other guests, but to themselves.  So if
you don't need to do those things, you can let them run
without all the black magic.  Let's take such conversation
out-of-band.  It doesn't belong on the LK list.

-Kevin

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Derek Fawcus]

On Fri, Jan 24, 2003 at 11:09:17AM -0800, Kevin Lawton wrote:
> --- Valdis.Kletnieks@vt.edu wrote:
> 
> > It turns out that the 99% of the work to cover the 1% of the cases is really
> > important.  The usual reason for doing VM is to isolate images from each
> > other
> 
> Plex86 can 100% isolate guests from each other.  What I'm saying
> is, it takes 99% of the work to do a full x86 VM which doesn't
> need those 2 macros for PUSHF/POPF.  (my oversimplified, but
> yet useful explanation of the state of affairs)
> 
> You have to do a lot of work to "get under the hood" of an
> OS, to fix up a few cases where if you let them run native,
> they'll get the wrong information or make the wrong thing
> happen.  Not to the other guests, but to themselves.  So if
> you don't need to do those things, you can let them run
> without all the black magic.  Let's take such conversation
> out-of-band.  It doesn't belong on the LK list.

Well actually I find it quite interesting...

One thing that seems to have been alluded to but not explicity stated
is just where is this patch going, and what affect will happen when
running a non 'VM friendly' OS under the 'new plex86'.

One thing that I'm curious about is how say thing'd work when running
a linux host, with a VM-friendly linux client,  and say a Win-2k
client.

I assume that the Win-2k client woudl end up having to trap to a
simulator (bochs) for it's ring 0 stuff.  But would things in the
above scenario work nicely,  with proper isolation between the
two (or more) clients?

DF

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Kevin Lawton]

--- Derek Fawcus <dfawcus@cisco.com> wrote:
> It doesn't belong on the LK list.
> 
> Well actually I find it quite interesting...
> 
> One thing that seems to have been alluded to but not explicity stated
> is just where is this patch going, and what affect will happen when
> running a non 'VM friendly' OS under the 'new plex86'.

The effect of a non VM'able guest would be it would go into the weeds.
And that effect is irrelevant to the LK list, be you interested or
not.  Because that involves no particular issues of Linux as
a host nor guest, not the simple patches I submitted.  Off-list, please.

-Kevin

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[David Lang]

it sounds like you are saying that with the plex86 you have two ways to
load a client OS.

1. 'normal', full isolation of VMs no modification of the client OS
needed.

2. 'nice VM'. modification of the client OS required, but with the
exception of the kernel level commands being eliminated in the
modification full VM isolation is still provided. Much better performance
then case #1

if you load a client OS and tell the system that it's a #2 when it's
really a #1 then you don't have valid isolation, but that's a sysadmin
error that you will allow to happen in order to make #2 possible.

is this correct

David Lang

On Fri, 24 Jan 2003, Kevin Lawton wrote:

> Date: Fri, 24 Jan 2003 12:56:58 -0800 (PST)
> From: Kevin Lawton <kevinlawton2001@yahoo.com>
> To: Derek Fawcus <dfawcus@cisco.com>
> Cc: Valdis.Kletnieks@vt.edu, Pavel Machek <pavel@ucw.cz>,
>      linux-kernel@vger.kernel.org
> Subject: Re: Simple patches for Linux as a guest OS in a plex86 VM
>     (please consider)
>
>
> --- Derek Fawcus <dfawcus@cisco.com> wrote:
> > It doesn't belong on the LK list.
> >
> > Well actually I find it quite interesting...
> >
> > One thing that seems to have been alluded to but not explicity stated
> > is just where is this patch going, and what affect will happen when
> > running a non 'VM friendly' OS under the 'new plex86'.
>
> The effect of a non VM'able guest would be it would go into the weeds.
> And that effect is irrelevant to the LK list, be you interested or
> not.  Because that involves no particular issues of Linux as
> a host nor guest, not the simple patches I submitted.  Off-list, please.
>
> -Kevin
>
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.yahoo.com
> -
> 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/
>

Re: Simple patches for Linux as a guest OS in a plex86 VM (please consider)

[Kevin Lawton]

--- David Lang <david.lang@digitalinsight.com> wrote:
> it sounds like you are saying that with the plex86 you have two ways to
> load a client OS.
> 
> 1. 'normal', full isolation of VMs no modification of the client OS
> needed.
> 
> 2. 'nice VM'. modification of the client OS required, but with the
> exception of the kernel level commands being eliminated in the
> modification full VM isolation is still provided. Much better performance
> then case #1

No, there's always full isolation.  If a guest is run without
mods similar to the ones I submitted for Linux, the interrupt
behaviour will not work correctly for the guest.  Neither
the host nor other guests will be affected.  Nor do I care,
because this is not for running arbitrary guest OSes.

x86 does not have pure VMability.  So, rather than trying real
hard to get under the hood to make it VM'able with heavy software
techniques, just forget about running all guest OSes and
run ones that can work, like Linux.

If you look, you'll notice my patches do nothing except macroize
the pushf/popf instructions to un-break the handling of eflags.IF
inside PVI mode (since x86 breaks it).  This has nothing to do
with isolation of the guest OS.  Nothing to do with running Windows.
Nothing to do with anything except running Linux as a guest.

-Kevin

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com