Date: Mon, 12 May 2008 21:31:01 +0200 From: Juergen Lock <nox@jelal.kn-bremen.de> To: Bakul Shah <bakul@bitblocks.com> Cc: freebsd-emulation@freebsd.org Subject: Re: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test new patch :) Message-ID: <20080512193101.GB11046@saturn.kn-bremen.de> In-Reply-To: <20080511235139.C9ECD5B58@mail.bitblocks.com> References: <20080511210518.GA46475@saturn.kn-bremen.de> <20080511235139.C9ECD5B58@mail.bitblocks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 11, 2008 at 04:51:39PM -0700, Bakul Shah wrote: > On Sun, 11 May 2008 23:05:18 +0200 Juergen Lock <nox@jelal.kn-bremen.de> wrote: > > > 4. "calcru: runtime went backwards from <t1> usec to <t2> for > > > pid <pid> (<cmd>)" is back! > > > > Well, the clock never was very accurate thats true... > > Simulated time will be slower than the real time by some > indeterminate amount but still all times ought to be > monotonically increasing. > Yeah not sure what kind of weird interaction causes this... > > > Random thoughts: > > > - If qemu is made scriptable we can automate a lot of > > > testing. For qemu/kqemu and freebsd. > > > > > Hmm what exactly do you want to script there? > > I don't have an "exact" idea but lots of vague ideas that need > fleshing out! > > Ideally, after every significant update, all the useful qemu > options get automatically tested. For that you need to be > able to control qemu's operation (and the guest OS!) and > capture useful information in case of bugs or crashes. Right > now you can emulate keyboard input via qemu's monitor > interface but you don't know how the guest OS reacts to it. > May be even snapshotting the console display to a .png file > on certain conditions can be very useful. Well you can use -nographic with a guest configured for serial console, then you have the guest on qemu's tty. (Ok this doesn't help much when you want to test under X, maybe there are special vnc clients for that, dunno...) > You want to be > able run a test manually and create an automated script from > it (e.g. when I run these set of things, this is what the > screen looks like except for that rectangle in the bottom > right corner!). And this has to happen relative to the > qemu's virtual time. > Hmm. > For testing a guest OS such as FreeBSD, one would like to > bootstrap a freshly built kernel and run a variety automated > tests against it. In case of the OS crashing you capture > backtrace, save the memory image in a dump file and contiue > testing. Hmm, maybe use qemu's gdbstub, set breakpoints on panic and trap_fatal and do a bt when they are reached; maybe you can even script kgdb to do that, dunno... Oh and btw if you run from an image you can actually mdconfig that and then fsck it as /dev/md0s1a etc. - thats sure faster than having the guest do it. > Doing this after a real machine crash is much more > painful. With qemu (or vmware) you just start up a whole > bunch of virtual machines (depending on available resources) > and do testing in parallel. All testing is repetitious so it > needs to be automated. > > > > - We need to add a section on qemu in the handbook. > > > > Hmmm... :) > > You just need to extend chapter 21 on Virtualization that > already talks about vmware, parallels, xen and virual PC. :-) Yeah, one of these days I guess... :) Juergen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080512193101.GB11046>