Re: [Qemu-devel] About qemu emulation speed (a question) and supported OS
On Tue, Sep 13, 2005 at 09:48:01PM -0500, Anthony Liguori wrote: Jim C. Brown wrote: The x86 cannot be virtualized in the Popek/Goldberg sense, so there's a couple of fast emulation techniques that are possible. Other than a hand coded dynamic translator, I reckon qemu + kqemu is about as good as it can get (unless I'm missing something here). qvm86 only virtualizes ring3 code. It doesn't handle ring 0 (e.g. kernel) at all. VMware handles kernel code. You are right that x86 code can't be 100% virtualized (even at the userland level) but VMware uses a lot of nasty disgusting tricks in order to work around them. (For example, playing with shadow pagetables so that a page of modified code is run but if the code tries to inspect itself it sees another (unexecuted) page that contains the original code.) Basically the original code is 'fixed' so it runs in ring 3, but this is still faster than translation. Do you have Do I have what? There are a couple of interesting paravirtualization techniques too. There's the Xen approach (really fast, but very invasive), the L4ka afterburning (theoritically close to as fast, but less invasive), and then of course the extremes like UML. Not familar with L4ka. I don't believe that UML does virtualization, it simply runs linux code 'as is' but intercepts calls to the kernel. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] About qemu emulation speed (a question) and supported OS
On Tue, Sep 13, 2005 at 11:27:39PM -0500, Anthony Liguori wrote: I reckon kqemu has this same problem... Technically, even in ring 3, if you run natively, you violate the Popek/Goldberg requirements because of cpuid. It's just not possible to trap it but it shouldn't matter for most software. It is possible to trap it, in a sense. You just read ahead and replace the cpuid instruction with something else. Ugly, but doable. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] About qemu emulation speed (a question) and supported OS
On Wed, 14 Sep 2005, Jim C. Brown wrote: Not familar with L4ka. I don't believe that UML does virtualization, it simply runs linux code 'as is' but intercepts calls to the kernel. UML does not do hardware virtualization. UML is a special architecture for the Linux kernel allowing Linux to run ontop of Linux. It does so by using it's own drivers and memory management, intercepting Linux system calls and playing with the page tables. All executed code is native in ring 3 (even the kernel parts, just a different memory mapping when the kernel code executes). The UML Linux kernel does not access any hardware, instead it provides drivers for simulated harddrives, serial ports etc translating these into suitable user-space actions on the host (i.e. read/writes to a block device is translated to read/writes in a file on the host, etc.. at the kernel driver level, not by hardware simulation/emulation/partitioning). The UML Linux kernel is running as a normal application on the host. But within the process virtual memory maps is provided for user-space applications and any systems calls made by user-space applications running there is intercepted with help from the syscall tracing facilities of the host and instead acted on by the UML Linux kernel. In theory UML should be able to run at native speed as there is no virtualization, translation or emulation involved, but as always there is overhead from various sources. To gain better performance the UML people is playing with a) More efficient management of multiple page tables for the same host process, allowing efficient switches between different contexts of the same process (kernel mode, user-space processes within UML etc). b) More efficient methods intercepting system calls. c) more efficient I/O drivers, mainly for block device access. Regards Henrik ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] About qemu emulation speed (a question) and supported OS
Two side footnotes to your comprehensive explanation: 1) with the SKAS host kernel patch you don't have to ptrace the guest processes and performance (and security) is improved quite a bit, I understand. 2) UML is currently being ported to run in ring 0. Why? Not for running on native hardware, but to run in VMX non-root mode on VT processors. This enables a host kernel module to use the VT extensions to run the UML guest with much better speed. The guest kernel can then easily take syscalls itself, manange its own page tables, etc. More details in the procedings of this year's Ottawa Linux Symposium. I think these both correspond to your points a) and b). Another neat thing UML can do by running in a process is directly mount host filesystems using the HostFS driver. Doing this in Xen is proving much harder (although my work is aiming for a slightly different set of functionality). Cheers, Mark On Wednesday 14 September 2005 16:47, Henrik Nordstrom wrote: On Wed, 14 Sep 2005, Jim C. Brown wrote: Not familar with L4ka. I don't believe that UML does virtualization, it simply runs linux code 'as is' but intercepts calls to the kernel. UML does not do hardware virtualization. UML is a special architecture for the Linux kernel allowing Linux to run ontop of Linux. It does so by using it's own drivers and memory management, intercepting Linux system calls and playing with the page tables. All executed code is native in ring 3 (even the kernel parts, just a different memory mapping when the kernel code executes). The UML Linux kernel does not access any hardware, instead it provides drivers for simulated harddrives, serial ports etc translating these into suitable user-space actions on the host (i.e. read/writes to a block device is translated to read/writes in a file on the host, etc.. at the kernel driver level, not by hardware simulation/emulation/partitioning). The UML Linux kernel is running as a normal application on the host. But within the process virtual memory maps is provided for user-space applications and any systems calls made by user-space applications running there is intercepted with help from the syscall tracing facilities of the host and instead acted on by the UML Linux kernel. In theory UML should be able to run at native speed as there is no virtualization, translation or emulation involved, but as always there is overhead from various sources. To gain better performance the UML people is playing with a) More efficient management of multiple page tables for the same host process, allowing efficient switches between different contexts of the same process (kernel mode, user-space processes within UML etc). b) More efficient methods intercepting system calls. c) more efficient I/O drivers, mainly for block device access. Regards Henrik ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] About qemu emulation speed (a question) and supported OS
There are a couple of interesting paravirtualization techniques too. There's the Xen approach (really fast, but very invasive), the L4ka afterburning (theoritically close to as fast, but less invasive), and then of course the extremes like UML. Not familar with L4ka. I don't believe that UML does virtualization, it simply runs linux code 'as is' but intercepts calls to the kernel. I don't want to put words in Anthony's mouth but I usually see UML as a rather (very) extreme case of paravirtualisation that barely preserves the underlying architecture's characteristics; I'm guessing that's what he meant... Cheers, Mark ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Real hard disk drive for Win2k/XP host
Thursday, September 15, 2005 12:39 AM Jim C. Brown wrote: I don't see any code for this in your patch. AFAIK qemu supports this already. I didn't know that. Thanks. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] About qemu emulation speed (a question) and supported OS
On Wed, Sep 14, 2005 at 01:46:58PM -0500, Anthony Liguori wrote: You can't readahead beyond a basic block. Taking a trap for each basic block and translating the block is what QEMU does. No, QEMU translates everything from guest machine code into its internal codes. I'm talking about using read ahead to change only those instructions which cause problems, and replacing them with instructions that are from the same instruction set I suppose you could call that emulation in a sense (as ur emulating the problematic instructions with other ones that create the behavior you need) but it is not the same as what QEMU currently does. Of course, VMware also emulates hardware, but you'd have to do that no matter what technique you use and it is a separate issue from emulation vs translation vs virtualization. (Theoretically VMware could just use a HAL layer like Xen does (or the newer plex86 did) and still be a virtualizer, but then it wouldn't work with unmodified guest OSes.) Regards, Anthony Liguori -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] About qemu emulation speed (a question) and supported OS
On Wed, Sep 14, 2005 at 10:18:24AM -0700, John R. Hogerhuis wrote: Why disgusting? Perhaps you meant disgusting because the Intel architecture forces a virtualizer to handle a bunch of corner cases like this. That is exactly what I mean. -- John. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu and AFS filesystem bugs?
I'm running qemu 0.7.2 on a Fedora Core 4 system (Opteron system), with OpenAFS 1.4.0-rc3. When I try to install either Windows 2000 or Red Hat WS, I am finding that if the guest install ISO image is on an AFS filesystem, I get strange errors during the install. On Windows, I would get 'file corrupted' when copying files in the initial install. Once the ISO image is in the AFS cache, it seems to work better. How would I go about debugging something like this? For what it's worth, other people have run VMware with ISO and disk images on AFS with no problems. -- -- Troy Benjegerdes'da hozer'[EMAIL PROTECTED] Somone asked me why I work on this free (http://www.fsf.org/philosophy/) software stuff and not get a real job. Charles Shultz had the best answer: Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life. -- Charles Shultz ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
