Re: [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)
On Thu, Aug 16, 2007 at 01:05:41PM -0400, Ben Taylor wrote: Personally, I'm not sure why we wouldn't just write out the command line data to a file tied to the primary image file What about a compatible change to the file format: the last 1024 bytes are either undefined, or, if a certain marker is present, an executable commandline? (I was going to say one standard sector, then I thought of how quickly i18n filenames add up.) This is metadata, I have a feeling that if we think about it there will be quite a lot of other metadata we'd like to store with the image. with some kind of time stamp to correlate the data from the command line and the last updated time of the primary image file. If there have to be separate files I'd prefer a weak hash to timestamps to avoid the common problems with unexpected drift and no way to calculate which changed and why. -- Dan Shearer [EMAIL PROTECTED]
Re: [Qemu-devel] Why not use exit() instead of abort()?
On Sun, Aug 05, 2007 at 11:13:55PM +0200, Bernhard Kauer wrote: There are a couple of places in qemu, where abort() is called. The most commonly used one is perhaps cpu_abort() which is called e.g. when a triple fault occures. As abort() does not call any atexit() function, cleanup is not performed. Tiny correction: abort() and _exit don't call atexit(), however unix-like OSs still cleanup memory and file descriptors and other transient resources anyway no matter how the program ended. So lack of cleanup isn't quite as big an issue as it might seem. This leaves for example the terminal in a state where the cursor is invisible. Non-transient resources such as DSOs and domain sockets are not cleaned up by the OS, which accounts for the terminal problem you noticed. Are there any reasons not to use exit(1) in cpu_abort()? Speed. I used to use abort() or _exit() for speed, ie they didn't hang around while atexit() waited politely for timeouts. I thought if I told the program to stop it should stop immediately :-) Then I had all sorts of problems to do with persistent shared resources hanging around in strange states so I moved to exit(1). I think (can someone correct me here?) there is another reason to call atexit() for portable programs, and that is that Microsoft OSs aren't as fussy about cleaning up after a program has exited. -- Dan Shearer [EMAIL PROTECTED]
Re: [Qemu-devel] replacing dyngen (was: S/390 host fixed)
On Wed, Aug 01, 2007 at 03:23:45PM +0100, Paul Brook wrote: Some parts of this code effectively are a special language for describing a CPU, that happen to be implemented using the C preprocessor :-) Right, in the same way that QEMU devices written in C are in a device language? :-) -- Dan Shearer [EMAIL PROTECTED]
[Qemu-devel] Virtualbox released under GPL2+
See http://www.virtualbox.org , a code release by InnoTek Systemberatung GmbH. heard about this a few minutes ago. It's published under GPL2 or higher. Some bits (such as the recompiler) are published under LGPL2.1 or higher. There's 464k lines of .cpp files, 487k lines of .h files. Seems to have been exclusively Windows, then ported to Linux. (Includes .exe files in the svn ;-) So far I notice lots of informative comments and code attributions. Nothing in the docs directory yet (perhaps that's in the user documentation on the website, haven't looked there yet.) They're keen on testcases. This is x86-on-x86 only from what I've seen of the source so far, with an impressive number of x86 hosts including OS/2 and Darwin apart from the obvious. 64bit as well as 32 hosts. I haven't seen any dynamic translation, it is all ring-0 stuff I think. There's a licensing bug; the Linux kernel module says GPL2 as per COPYING, but COPYING is in fact GPL2+. So far looks like a very tidy piece of work. Now to compile it and try it out... the debugger looks like it might have a nice idea or two in it. -- Dan Shearer [EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VirtualBox PC virtualization released as Open Source
On Mon, Jan 15, 2007 at 11:29:41PM +0100, Oliver Gerlich wrote: It seems like VB doesn't use something like -kernel-kqemu; during Ubuntu boot, host CPU was only used by userland apps, while with Qemu with -kernel-kqemu 80% of host CPU was used by kernel. According to http://www.virtualbox.org/wiki/VirtualBox%20architecture VB leans more to the kvm model, only they don't like VT/SMT much. From the arch document talking about what a VB host can be running at any given time. I think your observation about CPU usage is accounted for in point 3 below: --- start quote 1. Your CPU can be executing host ring-3 code (e.g. from other host processes), or host ring-0 code, just as it would be if VirtualBox wasn't running. 2. Your CPU can be emulating guest code (within the ring-3 host VM process). Basically, VirtualBox tries to run as much guest code natively as possible. But it can (slowly) emulate guest code as a fallback when it is not sure what the guest system is doing, or when the performance penalty of emulation is not too high. Our emulator (in src/emulator/) is based on QEMU and typically steps in when * guest code disables interrupts and VirtualBox cannot figure out when they will be switched back on (in these situations, VirtualBox actually analyzes the guest code using its own disassembler in src/VBox/Disassembler/); * for execution of certain single instructions; this typically happens when a nasty guest instruction such as LIDT has caused a trap and needs to be emulated; * for any real-mode code (e.g. BIOS code, a DOS guest, or any operating system startup). 3. Your CPU can be running guest ring-3 code natively (within the ring-3 host VM process). With VirtualBox, we call this raw ring 3. This is, of course, the most efficient way to run the guest, and hopefully we don't leave this mode too often. The more we do, the slower the VM is compared to a native OS, because all context switches are very expensive. 4. Your CPU can be running guest ring-0 code natively. Here is where things get hairy: The guest only thinks it's running ring-0 code, but VirtualBox has fooled the guest OS to instead enter ring 1 (which is normally unused with x86 operating systems). --- end quote -- Dan Shearer [EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
