Wow Oiaohm! That was a very interesting post. I'll have to mull it over a few more times. Not quite sure what you mean by a few things. By "qemu usermode emulation", do you mean that the entire QEMU emulator is running in user space, instead of kernel space, or do you mean that QEMU emulates a usermode? When you say > It emulates at the syscall to kernel point. So every time [an] application does a syscall the syscall is processed natively. , do you mean that an application running in the guest operating system passes a syscall to the guest "kernel," which is rigged to be a paravirtualized guest, then the special guest OS passes this application call to QEMU, which QEMU then passes to the host operating system to handle natively? So this "syscall to kernel point" emulation is only possible with paravirtualization? If the guest is Linux, and the host is Windows, how can Windows answer Linux function calls from applications in the virtual machine? I think you must mean something different that what I'm thinking you meant. One a different note in the same score, I Googled more on this Web code-Virtualization stuff. I found a PC emulator written in JavaScript: http://bellard.org/jslinux/. If you follow that link, you actually will load Linux in a tab in your wed browser! Pretty cool, huh? As terrible of an idea as it might seem, I wondered if it is possible to convert C/ C++ source code into Java code. That is to compile for JVM instead of machine code. Then, assuming QEMU is written in C/ C++, one could run the source code through the converter and embed the code into a webpage, having QEMU online. Turns out that there is a C to Java converter. I wonder if the idea would work. Unorthodox enough? Considering the WINE in Linux in Ubuntu idea, I was concerned about graphics. We need paravirtualization (period). We also need paravirtualization that renders on the real graphics card (as a specific subset). Running games in WINE in Linux in a PC emulator in a web browser in a host operating system when running the game on emulated graphics in the same amount of nesting is a fail. You need paravirtualization to send graphics calls to the graphics card. Then I remembered WebGL. WebGL is based on OpenGL and is a library that extends....JavaScript! And we have already seen someone make a PC emulator in JavaScript. So, hopefully, it's not too much to ask for a JavaScript PC emulator/ virtualizer that has WebGL and paravirtualization. A virtual machine in such a hypervisor/ emulator could render games on the real graphics card. And a hard disk image with a paravirtual guest installed can theoretically be portable from one hypervisor to another in a better way than non-paravirtual guests can potentially be portable from one hypervisor to another, BTW. It would be really groovy if we had a paravirtualization hypervisor embedded in a webpage that could detect the architecture of your processor, and based on that, determine if it has to emulate a processor or not. And furthermore it run off files and folders on your local hard drive that you may download, that it support WebGL, and that we have a Linux with the right modules inserted to run in this omnipresent VM. You don't even need those files and folders that make up the guest to be in a hard disk image because this is paravirtualization. Why waste resources emulating a hard drive? The hypervisor simply executes the kernel image like a supervisor executes a binary. WINE makes all graphics calls go to OpenGL, and that should marry just fine with WebGL. Then the game would render on your real graphics card. Might not want Compiz enabled, though [Wink] . It seems as though exporting syscalls from applications running in the VM to the host operating system, which would be useful in reducing code that has to go through a processor emulator (if emulating a processor), like Oiaohm was saying, is only possible if the host OS is Linux. But Oiaohm seemed to be saying that QEMU gets around that and has the host OS answer system calls anyways? Is QEMU a multi-platform reverse WINE? Would it be better for an online hypervisor (that's almost type 3!) to be written in something like Google Go, rather than JavaScript? Either way, it's not a compiled language, so I don't see an efficiency gain in that regard. So the last efficiency would be to have the user download and install a hypervisor for their machine code. But that would put us back at square one. Maybe the lesson here is that the Web isn't the only safe universal platform. Cheers, Jake
