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] Using Microsoft-provided Windows images
I have been playing around with the demonstration Windows images downloadable from Microsoft just to see how hard it would be to use the OSs they provide. The images are designed for Microsoft Virtual Server, but can be successfully converted to qcow2 and vhdx using qemu-img. QEMU won't boot the images (not a difficult problem, I think) but VMware can. I'll try other free virtualisation systems at some point. See http://shearer.org/Microsoft_Demo_VMs for my notes so far. -- Dan Shearer [EMAIL PROTECTED]
Re: [Qemu-devel] [PATCH] S/390 host fixed
On Wed, Aug 01, 2007 at 02:02:13AM +0100, Paul Brook wrote: > I suspect making dyngen handle jump tables is not going to happen. Which brings up the question of dyngen. Very clever and a very good way of bootstrapping QEMU in the early days, but too brittle going forwards now the rest of QEMU works so well. You had an alternative approach to dyngen, pointed at here: http://lists.gnu.org/archive/html/qemu-devel/2006-10/msg00227.html Any thoughts about the future of hand-coded backends in QEMU? I wasn't convinced at first (and, given resources, it isn't nearly as good as a special-purpose language for describing CPUs at this level) but I now think your work is a very good solution for bootstrapping QEMU to the next level of users. -- Dan Shearer [EMAIL PROTECTED]
Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)
On Fri, Jul 27, 2007 at 05:50:05PM +0200, Sunil Amitkumar Janki wrote: > Dan Shearer wrote: > >You do also have the architectures provided to you by QEMU :-) :-) > > Maybe in the future where we have all kinds of cheap multicore processors > this will not matter much but for the moment limited resources are still > some > kind of hindrance to realizing the benefits of multi-architecture emulation. In the special case of repeat automated test compiles where the only output is a short status message from time to time, the lack of speed is less of a problem. You do end up with a machine that creates the maximum amount of noise the hardware is capable of, and runs very hot :-) -- Dan Shearer [EMAIL PROTECTED]
Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)
On Fri, Jul 27, 2007 at 04:58:19PM +0200, Sunil Amitkumar Janki wrote: > Dan Shearer wrote: > > > >I see this as a different class of testing to the tinderbox-style > >testing Natalia Portillo was talking about, checking out and compiling > >under different circumstances. That's very valuable, and will help > >address a problem that drives away a lot of potential QEMU users - they > >just can't compile it. > > That would be great. I am regularly compiling and using QEMU CVS > snapshots because features get added all the time. A lot of the time > it happens that these build fine on x86 whereas they don't work on > other architectures because the developers don't have access to those. > > I have been running self-built Slackware 12.0 on MIPS for the last > few months and would like to run QEMU on that architecture. previously > it built but didn't run, but now it doesn't even compile anymore. The > error message I get is the following: This is one of the three reasons why I say it is better to do tinerbox-type testing inside a VM. If you could make the precise QEMU MIPS target image that fails to build QEMU available online then it is easier for everyone to see the context. (The other two reasons are that it is a good workout for the simulator, and general dogfood-ness for the developers who are forced to become aware of problems that would otherwise only be noticed by minority users such as you :-) > I will try to get SPARC Linux and Solaris running on my newly acquired Sun > Enterprise 250 server and compile there as well so I can test snapshots on > all the architectures I have at my disposal. You do also have the architectures provided to you by QEMU :-) :-) -- Dan Shearer [EMAIL PROTECTED]
Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)
On Fri, Jul 27, 2007 at 09:29:11AM -0500, Anthony Liguori wrote: > FYI, I've started building a VNC based automated tester. You provide it > a series of screenshots with masks of data that's likely to be That's excellent. I see this as a different class of testing to the tinderbox-style testing Natalia Portillo was talking about, checking out and compiling under different circumstances. That's very valuable, and will help address a problem that drives away a lot of potential QEMU users - they just can't compile it. -- Dan Shearer [EMAIL PROTECTED]
Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)
On Sun, Apr 08, 2007 at 09:43:20PM +0100, Natalia Portillo wrote: Whoops, slightly late reply :-) > I have a huge list of operating systems (both closed and open source, that > works and that doesn't work under QEMU) that can be used to check that QEMU > doesn't broke (or even, that it corrects a non-working state). Where the problem with QEMU is not something basic (eg doesn't boot) it can be useful to use nested virtualisation. Although QEMU in QEMU is of course slow because that case hasn't been optimised, if you have a single image within which are many other images savevm'd just before the error condition occurs, you can run a repeatable testsuite quite quickly. And since you can snapshot the outer image, you know that you are running these tests in exactly the same way every time. (There are a lot of other uses for recursive virtualisation, I'm a fan of it!) > And I think it is better to check an installed image that to test it only > boots or installs (faster at least). Agreed. As to installs I had to do something similar for different VM systems a while ago and I found it useful to have a frozen image just before the typical "detecting hardware" phase of an installation. The point of this was not to compare the hardware that was detected, just to detect major malfunctions. Hardware probing like this is uniquely stressful. It isn't hard to notice if an installer crashes, or the VM crashes, or there's lot's of errors. > Fabrice and me discussed about taking screenshot per some seconds to compare > with known took screenshots and if something fails shutdown the VM and send > an email. > > But that required some macro interface "click at x,y, wait some seconds, > press 'k' key", that is not currently under QEMU. Why can't you redirect the QEMU monitor to something easily accessible, eg a virtual serial port, and then use mouse_move and sendkey monitor commands to drive testing, and screendump to save images for comparison? Those commands have been in the monitor for years, so is there something I'm not understanding here? > The best solution I think is to get a way to send QEMU the screenshot to > file command some times and stop the VM when both are equal, then send the > last took screenshot to a mail address so breakability can be checked. (If > it is the login window, great, it BOOTS!, if not, it doesn't) > > What do you think? The problem is synchronisation given that QEMU has no guaranteed time domain, so you don't know if your target is failing or just being slow so you keep on taking screenshots for a ridiculously long time. You can take fewer screenshots if you have some out-of-band signal. For example knowing to expect a particular screenshot around the time that a particular file is touched or a particular hardware device is initialised, or a magic QEMU-specific CPU instruction is executed. > I have enough spare space to hold the boot images (600Gibibytes free), and a > machine that should be able to automatically checkout and compile QEMU > (Athlon XP 2000+, 768Mb RAM, 600GiB free, Gentoo Linux). Compiling is really important. Even without testing targets, this would be a very good community service if you want to do even just this much. Compiling a simulator under itself in all supported configurations is an important set of tests (compile/run MIPS under IA32, IA32 under PPC32, etc especially 32/64 mixes, then the different supported compiler versions, and then a couple of different Linux distributions with their different choices of library versions and configurations.) This is probably 24 hours of hard work. I have seen simulators choke on these sorts of tests. > Just, I have not the knowledge to make the script that boots qemu, says qemu > to take the screenshot, compares the took one with the last one, stops qemu, > sends the last screenshot by email, compresses all took screenshots, goes to > next VM, so on. (Preferibly without X11 running, as the machine is a mostly > headless P2P and File server) I think this can be simplified. Care to send a copy offlist of what you've done and i'll have a look at it? -- Dan Shearer [EMAIL PROTECTED]
Re: [Qemu-devel] Two quick requests.
On Fri, Feb 09, 2007 at 10:27:08PM +, Paul Brook wrote: > On Friday 09 February 2007 22:19, Rob Landley wrote: > > 1) When you accidentally run qemu as root, could it NOT try to go into a > > full-screen display by default resulting in a corrupted display you can't > > break out of and have to power cycle the machine? > > This is a feature of your SDL libraries. They're probably trying to use > console framebuffer output. Complain to whoever supplied your SDL libraries. True but I think Rob wants to prevent the "accidentally" bit because that isn't the only bad thing you can do with QEMU as root by accident. The user's intention can be (more or less) detected with a parameter like "-force-run-as-root". Since once of QEMU's main points is to avoid the need for root access I think that's reasonable. -- 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
[Qemu-devel] Re: Virtualbox released under GPL2+
Ok ok, so the list archives give no result for "Virtualbox" and I only just rejoined... yes I now realise everyone else knwos all about VirtualBox. Sorry for the noise :-) -- Dan Shearer [EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[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
