Well, today I had the idea of incorporating a few virtual machines into the linux kernel. I had this idea because today, it is no longer viable or oeconomical to keep old computers running, while powerful, modern computers are becoming plentiful and.

For example, the place where my father works has two PDP-10s and two KDF-9s. The PDP-10s are connected as an asymmetric multiprocessor system for real-time simulations and interactive computing, whilst the two KDF-9s are hooked up to the master PDP-10 through bidirectional parallel ports to do batch processing and background jobs and such. Well, I suppose this could all be moved into an old pentium computer or something, because that arrangement is not exactly easy to maintain these days, hardware-wise, but it is a simple set-up to

But anyway, are people interested in virtualising computers and emulating processors inside the linux kernel? We already have this for running IA-32 binaries on AMD64 processor, as I do everyday at home. But these are the kind of advantages I am thinking of:

- Win32 applications would be able to run on computers other than i386-based ones, such as the G3 macs or something using Wine to interface to the GUI,
- or CP/M applications would be able to run on top of an emulated Z80 chip, sharing the resources of the host computer through a system call and API translation similar to what Wine provides for Win32 and Win16 applications,
- closed-sources binaries, for example 'Google Earth' or the Opera browser, will run on architectures other than those for which they were written.
- Cross development for embedded systems and what-not.
- To be able to run old operating systems on top of a modern one would be an easy step towards migrating from deprecated architectures that aren't commercially supported any more.
- To virtualise computers may take up a lot of computational power, but moving that out of userspace and into the kernel makes the process less CPU hungry, with the added bonus of being able to use the resources of the host computer more effectively.

Sounds to me like you are talking about emulation (pretending to be hardware you are not) rather than virtualization (pretending a VM has exclusive use, rather than shared use, of hardware). Emulation is expensive in terms of CPU usage because it has to pretend to do all the low-level operations through high-level commands.

In my opinion, emulators should always be user-space rather than kernel-space.

Ah, perhaps I haven't explained myself properly because I am envisaging something that perhaps doesn't exist in today's practices in virtualisations and emulations, and because I don't speak English well when I'm tired...

But perhaps emulation is the correct term: something in the kernel that emulates the i686 processor, (and perhaps also a BIOS of sorts) would allow Wine to run Win32 applications on computers other than the ones which run Windows because the code of the application runs on a virtual machine or an emulator (whichever one it would be). Dosbox could be written to use the same code in the kernel.

And then, if someone could write a Z80 emulator into the kernel (several open-source ones exist already), and some kind of translation of the API of CP/M and co. existed, then CP/M applications could seem to be running on the host computer, with access to the hard drives, ethernet ports, and whatever else of the host computer.

If, on the other hand, these emulations were running in user-space, then these applications would not be able to run as happily as part of the system in it's entirety. Virtual machines we already have. I am looking to provide a way of being able to run foreign applications on the host computer by means of emulating parts of the computer, and translating syscalls like Wine does.

Even if the application you want to use is,say, a Z80 binary for CP/M, and you want it to run as if natively?

I don't think I'm following.

If you want to run x86 programs on non-x86 CPUs, that is emulation. If you are running Windows on a G3, that is emulation.

If you are running Wine, that is kinda-virtualization, because Wine is a bunch of DLLs and associated userspace hooks that make Windows programs think they are running on Windows.

This stuff doesn't belong in the kernel because it is going to be very large, very complicated, and would only appeal to a small subset of users. And being very large and very complex, bugs would make the kernel more vulnerable to crashes or problems.

Some of the Wine folks are talking about the long-term goal of moving Wine out of userspace. Linus himself is not against having Win32 system call support in the kernel...

But we have ELF support in the kernel, and commonly a.out support is compiled into the kernel too, as well as support for 32-bit binaries on 64-bit kernels, so why not even the .COM and .EXE formats from the MS-DOS and Windows worlds too, even on Linux kernels not running on the Intel range of processors? That would be emulation, because .COM and .EXE are necessarily Z80, x88 or x86 code. But then, Windows system calls need to be trapped and passed to Wine, and a similar solution for MS-DOS and CP/M applications.

In the same way providing support for binaries from other platforms in a very similar way, for example the plethora of Macintosh software or the Acorn machines or whatever there is interest for.

It could be a better solution than using a virtual machine, I feel.