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

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

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");
}

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

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

<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....

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

--Kai

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

What about:

.macro pushfl
call __pushfl
.endm

.macro popfl
call __popfl
.endm

There, nice and small.

-- Jamie

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

Hi!

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?

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

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

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

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

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

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

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