[Qemu-devel] testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD...

[Qemu-devel] testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD...

[Juergen Lock]

Hi!

 After discovering a workaround for the -kernel-kqemu userspace pio bug
in connection with vmware svga/vmmouse a few days ago I made another
experimental FreeBSD qemu-devel port update today,
	http://people.freebsd.org/~nox/qemu/qemu-devel-20090218.patch
with the mentioned patches added (the vmware_vga.c depth fix hasn't
been committed yet so I added it to files/patch-hw-vmware_vga.c for now;
the userspace pio workaround patch needed an additional TARGET_I386
check since vmware_vga.c now also gets built for mips targets, see
files/patch-iopl-workaround .)

 Apart from the usb thruput regression with (some?) recent Linux guests
that I already had been mentioning a few times (no change there) and the
recent discussion of qcow2 corruption that was seen with (at least) win2k
guests on recent kvm (which uses similar qcow2 code than qemu svn, see
this thread:
	http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00713.html
- the consensus on that thread seems to be that qcow(2) code has always
been experimental and you should use raw images if you want reliability;
raw is also usually faster) - apart from these two issues this snapshot
is looking pretty good in my (limited) testing so far; you are encouraged
to test it with your various guests that you have lying around, if it
works for you as well maybe we can indeed update the FreeBSD qemu-devel
port again before the next official qemu release gets cut...

 For the curious, and to get more people testing this, :) here is a
reiteration of a few of the improvements made since the snapshot thats
currently in ports (qemu-devel), in no particular order:

- tcg conversion complete (no longer depends on gcc3)
- gdbstub improvements, like managing cpus as threads, working breakpoints
  etc with -smp, watchpoints...
- added cdc ethernet usb nic (-usbdevice net:)
- e1000 pxe rom, tso, vlan, and other fixes/improvements
- scsi emulation fixes/improvements
- 16550A uart (serial) emulation, reported to work with the new uart(4)
  in FreeBSD-current guests too (except for BREAK_TO_DEBUGGER, altho I
  don't know whether that even works on real hw now so it might not
  actually be qemu's fault)
- no longer depends on aio(4) so no more chances to forget to kldload
  that (uses its own threads now)
- 64 bit host fixes for slirp (-net user)
- added instruction counter
- emulate core2duo and phenom cpus, x86 CPUID extended family/model
  (for example emulate newer amd cpu as:
  -cpu qemu64,family=15,model=65,stepping=3)
- added -clock dynticks support for FreeBSD hosts
- added -serial msmouse (Microsoft serial mouse emulation)
- virtio-{blk,net,balloon,console} (paravirtualization via emulated pci
  devices and corresponding guest drivers)
- added -net channel ... to forward guest slirp tcp connections to
  qemu character devices
- hpet emulation
- (some?) ipv6 support for like vnc
- added a -vga none cli option (the other vga options have been renamed
  too, now you do -vga {none,cirrus,std,vmware} ...)
- fixed media detection on emulated cdroms (helps some Linux guests)
- added -rtc-td-hack option to fix time drift with RTC on Windows
- added "serial" parameter to -drive flag (to specify emulated disk's
  serial number)
- added new option "werror" to -drive flag:
  possible values are:
    report    - report errors to a guest as IO errors
    ignore    - continue as if nothing happened
    stop      - stop VM on any error and retry last command on resume
    enospc    - stop vm on ENOSPC error and retry last command on resume
                all other errors are reported to a guest.
  default is "report"
- added snapshot subcommand for qemu-img (to list, create, apply and delete
  snapshots on qcow2 images)
- x86 now issues reset on triple faults
- (untested on FreeBSD:) live migration support, basic audio functionality
  for vnc.c - malc's ad-hoc client for capturing A/V of running guests is
  here:
	http://repo.or.cz/w/qemu/malc.git?a=tree;f=vcap;hb=capture3
- and of course all kinds of bugfixes, bios updates (rumors are that vista
  guests work now?), and also improvements to non-x86 targets...

 And last, but far from least:

FreeBSD host TODOs - help more than welcome here: (this stuff is working
on Linux hosts, except maybe bsd-user...)

- complete the usb host support (auto dis/connects, isochronous for eg
  webcams etc, support the new usb stack in FreeBSD-current - the original
  author of the FreeBSD usb host patches says he is too busy with other
  stuff now ):
- same for bluetooth...
- scsi passthru support (so you can use eg tape drives or maybe burn
  cds/dvds from guests)
- add arm/ppc/sparc(?) host support to the port(s)
- kvm port!  There was a soc project but it never reached the state of
  entering ports,
	http://wiki.freebsd.org/FabioChecconi/PortingLinuxKVMToFreeBSD
  - and now of course both kvm and the FreeBSD kernel have evolved
  further, and also the first pieces of kvm userland support code have
  entered qemu svn, and it seems at least some people _might_ want to
  retire kqemu some time in the future too, see this thread...
	http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00326.html
- test/fix bsd-user (qemu-sparc64; i386 host linker script seems to be
  needed at the very least)
- write/port virtio guest drivers for FreeBSD (will also be useful for
  kvm hosts which are getting more common even tho at least atm they
  have to run Linux...)

 If you have read until here, thanx! :)
	Juergen

[Qemu-devel] Re: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD...

[Gary Jennejohn]

On Mon, 23 Feb 2009 22:19:33 +0100
Juergen Lock <nox@jelal.kn-bremen.de> wrote:

> On Mon, Feb 23, 2009 at 03:47:24PM +0100, Gary Jennejohn wrote:
> > On Sun, 22 Feb 2009 02:37:47 +0100
> > Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> > 
> > > been experimental and you should use raw images if you want reliability;
> > > raw is also usually faster) - apart from these two issues this snapshot
> > > is looking pretty good in my (limited) testing so far; you are encouraged
> > > to test it with your various guests that you have lying around, if it
> > > works for you as well maybe we can indeed update the FreeBSD qemu-devel
> > > port again before the next official qemu release gets cut...
> > > 
> > 
> > Well, I applied the patches and installed qemu.
> > 
> > I tried installing openSUSELinux 10.3 because I had a DVD laying around.
> > 
> > I used a 150GB raw image created using qemu-img.  I did not use kqemu.
> > I started qemu with this command line:
> > 
> > qemu -boot d -cdrom /dev/acd0 -hda linux.img -localtime -m 1G
> > 
> > Note I have an AMD64 X2 with 4GB of RAM installed running 8-current.
> > 
> > It got up to the point where it actually started the install and then
> > croaked with SIGSEGV, I think it was.  The error message flashed by
> > rather quickly.
> > 
> > That means that I was able to partition the disks and specify some
> > non-standard packages. It managed to create and format the disk
> > partitions and figure out from the DVD which packages to install.
> > 
> > Not too bad, I suppose.
> 
> A SIGSEGV, hmm.  What I do see sometimes especially without kqemu is guest
> failures related to various kinds of timeouts, i.e. guests not expecting
> running as slowly...  tho a SIGSEGV is probably something different.
>

I tried the installation a few more times using the patched qemu-devel
and was able to see that the error was indeed a segmentation violation
in Yast.call, whatever that may mean.

> You could try a few things:
> a) the same with kqemu (userland), in case its a tcg bug (or indeed a
>    timeout; remember to rebuild qemu in case you built it without the
>    kqemu knob enabled or otherwise kqemu won't get used), and also
> b) another time with -kernel-kqemu in case its a tcg bug affecting
>    guest kernel code (altho of course in both cases kqemu can cause its
>    own kind of failures, even more so with amd64 guests...)
>

I'll consider doing these steps with the patched qemu-devel later.

> c) try the same with the original qemu-devel port and also with qemu 0.9.1
>    (the qemu port), in case its a regression (possibly caused by the tcg
>    conversion?)
>

qemu never gets past the initial openSUSE install screen.  It just sits
there eating 100% of the CPU without any visible progress.

I tried qemu-devel with kqemu.ko loaded but it never got past loading the
Linux kernel.  It hung at various boot stages with no apparent pattern.

Without kqemu.ko it is actually doing the install as I write this.  Have
to wait and see just how far it gets.

One difference between now and before is that I have vfs_aio in the
kernel.  I'm also running a brand-new kernel from today.

BTW this is the command line which I used:
qemu -net none -m 1G -boot d -cdrom /dev/acd0 -hda linux.img -localtime -std-vga

> d) see if you can enable coredumps in the guest in order to find out more
>    about your particular failure.
> 

Well, supposedly Yast.call dumped core, but since the Linux install runs
out of a memory disk there's no way for me to see it.

I have no idea how to enable coredumps such that I can acccess any coredumps
which may be made.

>  Oh and if you do any of these you may want to also Cc the qemu list with
> your findings, they are probably interested as well...
> 

OK, added.

---
Gary Jennejohn

[Qemu-devel] Re: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD...

[Gary Jennejohn]

On Mon, 23 Feb 2009 22:19:33 +0100
Juergen Lock <nox@jelal.kn-bremen.de> wrote:

> You could try a few things:
> a) the same with kqemu (userland), in case its a tcg bug (or indeed a
>    timeout; remember to rebuild qemu in case you built it without the
>    kqemu knob enabled or otherwise kqemu won't get used), and also
> b) another time with -kernel-kqemu in case its a tcg bug affecting
>    guest kernel code (altho of course in both cases kqemu can cause its
>    own kind of failures, even more so with amd64 guests...)
>  

Neither of these work.  The only way I can get past loading the kernel
is with -no-kqemu.

I still see the segmentation fault in Yast.call.  Now I know that it's
in line 486, if that's of any interest.

Sorry, I'm not going to invest any more time in this.

---
Gary Jennejohn

[Qemu-devel] Re: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD...

[Juergen Lock]

On Wed, Feb 25, 2009 at 08:15:50PM +0100, Gary Jennejohn wrote:
> On Mon, 23 Feb 2009 22:19:33 +0100
> Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> 
> > You could try a few things:
> > a) the same with kqemu (userland), in case its a tcg bug (or indeed a
> >    timeout; remember to rebuild qemu in case you built it without the
> >    kqemu knob enabled or otherwise kqemu won't get used), and also
> > b) another time with -kernel-kqemu in case its a tcg bug affecting
> >    guest kernel code (altho of course in both cases kqemu can cause its
> >    own kind of failures, even more so with amd64 guests...)
> >  
> 
> Neither of these work.  The only way I can get past loading the kernel
> is with -no-kqemu.
> 
> I still see the segmentation fault in Yast.call.  Now I know that it's
> in line 486, if that's of any interest.
> 
> Sorry, I'm not going to invest any more time in this.

Thanx.  Can someone else verify that kqemu still works on FreeBSD-current?
It is possible that you got hit by the kqemu tsc vs smp problem, i.e.
passing `notsc' to the guest kernel or forcing qemu onto one cpu
(cpuset -l 0 qemu ...) may have helped there, sorry I should have thought
of that earlier...

 Also, did I get that right that this opensuse 10.3 install worked with
the original qemu-devel port (without kqemu)?  So we do seem to have a
regression here...  (thats a 20080620 qemu svn snapshot, for the folks
on the qemu list.)

 Thanx,
	Juergen

[Qemu-devel] Re: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD...

[Gary Jennejohn]

On Sat, 28 Feb 2009 18:15:20 +0100
Juergen Lock <nox@jelal.kn-bremen.de> wrote:

> On Wed, Feb 25, 2009 at 08:15:50PM +0100, Gary Jennejohn wrote:
> > On Mon, 23 Feb 2009 22:19:33 +0100
> > Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> > 
> > > You could try a few things:
> > > a) the same with kqemu (userland), in case its a tcg bug (or indeed a
> > >    timeout; remember to rebuild qemu in case you built it without the
> > >    kqemu knob enabled or otherwise kqemu won't get used), and also
> > > b) another time with -kernel-kqemu in case its a tcg bug affecting
> > >    guest kernel code (altho of course in both cases kqemu can cause its
> > >    own kind of failures, even more so with amd64 guests...)
> > >  
> > 
> > Neither of these work.  The only way I can get past loading the kernel
> > is with -no-kqemu.
> > 
> > I still see the segmentation fault in Yast.call.  Now I know that it's
> > in line 486, if that's of any interest.
> > 
> > Sorry, I'm not going to invest any more time in this.
> 
> Thanx.  Can someone else verify that kqemu still works on FreeBSD-current?
>

I went back to openSUSE with the standard qemu-devel.  I found that I
could (usually) boot w/o problems if I put -no-acpi on the CL.

Right now I have openSUSE runngin pretty well.  It's nearly as fast as
on my old (genuine) IBM X31 laptop :)

> It is possible that you got hit by the kqemu tsc vs smp problem, i.e.
> passing `notsc' to the guest kernel or forcing qemu onto one cpu
> (cpuset -l 0 qemu ...) may have helped there, sorry I should have thought
> of that earlier...
> 

I just tried these suggestions (with the standard qemu-devel) and they
don't seem to do any harm :-P

>  Also, did I get that right that this opensuse 10.3 install worked with
> the original qemu-devel port (without kqemu)?  So we do seem to have a
> regression here...  (thats a 20080620 qemu svn snapshot, for the folks
> on the qemu list.)
> 

See above.

Now I'm thinking about giving the patched qemu-devel another try, since
I've found some workarounds for booting.  I'll see whether I can at least
boot into the installed openSUSE using it.

---
Gary Jennejohn

[Qemu-devel] Re: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD...

[Juergen Lock]

On Sat, Feb 28, 2009 at 08:16:50PM +0100, Gary Jennejohn wrote:
> On Sat, 28 Feb 2009 18:15:20 +0100
> Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> 
> > On Wed, Feb 25, 2009 at 08:15:50PM +0100, Gary Jennejohn wrote:
> > > On Mon, 23 Feb 2009 22:19:33 +0100
> > > Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> > > 
> > > > You could try a few things:
> > > > a) the same with kqemu (userland), in case its a tcg bug (or indeed a
> > > >    timeout; remember to rebuild qemu in case you built it without the
> > > >    kqemu knob enabled or otherwise kqemu won't get used), and also
> > > > b) another time with -kernel-kqemu in case its a tcg bug affecting
> > > >    guest kernel code (altho of course in both cases kqemu can cause its
> > > >    own kind of failures, even more so with amd64 guests...)
> > > >  
> > > 
> > > Neither of these work.  The only way I can get past loading the kernel
> > > is with -no-kqemu.
> > > 
> > > I still see the segmentation fault in Yast.call.  Now I know that it's
> > > in line 486, if that's of any interest.
> > > 
> > > Sorry, I'm not going to invest any more time in this.
> > 
> > Thanx.  Can someone else verify that kqemu still works on FreeBSD-current?
> >
> 
> I went back to openSUSE with the standard qemu-devel.  I found that I
> could (usually) boot w/o problems if I put -no-acpi on the CL.
> 
> Right now I have openSUSE runngin pretty well.  It's nearly as fast as
> on my old (genuine) IBM X31 laptop :)
> 
> > It is possible that you got hit by the kqemu tsc vs smp problem, i.e.
> > passing `notsc' to the guest kernel or forcing qemu onto one cpu
> > (cpuset -l 0 qemu ...) may have helped there, sorry I should have thought
> > of that earlier...
> > 
> 
> I just tried these suggestions (with the standard qemu-devel) and they
> don't seem to do any harm :-P
> 
..but they didn't help either?  (i.e. w/o -no-acpi)

> >  Also, did I get that right that this opensuse 10.3 install worked with
> > the original qemu-devel port (without kqemu)?  So we do seem to have a
> > regression here...  (thats a 20080620 qemu svn snapshot, for the folks
> > on the qemu list.)
> > 
> 
> See above.
> 
> Now I'm thinking about giving the patched qemu-devel another try, since
> I've found some workarounds for booting.  I'll see whether I can at least
> boot into the installed openSUSE using it.

 Thanx, :)
	Juergen

[Qemu-devel] Re: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD...

[Gary Jennejohn]

On Sat, 28 Feb 2009 22:36:20 +0100
Juergen Lock <nox@jelal.kn-bremen.de> wrote:

> On Sat, Feb 28, 2009 at 08:16:50PM +0100, Gary Jennejohn wrote:
{snip old stuff]
> > > It is possible that you got hit by the kqemu tsc vs smp problem, i.e.
> > > passing `notsc' to the guest kernel or forcing qemu onto one cpu
> > > (cpuset -l 0 qemu ...) may have helped there, sorry I should have thought
> > > of that earlier...
> > > 
> > 
> > I just tried these suggestions (with the standard qemu-devel) and they
> > don't seem to do any harm :-P
> > 
> ..but they didn't help either?  (i.e. w/o -no-acpi)
>

Yes it did.  It boots without -no-apci and with notpc just fine.

> > 
> > Now I'm thinking about giving the patched qemu-devel another try, since
> > I've found some workarounds for booting.  I'll see whether I can at least
> > boot into the installed openSUSE using it.
> 

OK, the patched qemu-devel can boot the already installed openSUSE.

I tried it with and without kernel-kqemu and both worked as long as
I booted with notpc.

Can't explain why the installation failed, though.

---
Gary Jennejohn

[Qemu-devel] Re: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD...

[Juergen Lock]

On Sun, Mar 01, 2009 at 06:57:09PM +0100, Gary Jennejohn wrote:
> On Sat, 28 Feb 2009 22:36:20 +0100
> Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> 
> > On Sat, Feb 28, 2009 at 08:16:50PM +0100, Gary Jennejohn wrote:
> {snip old stuff]
> > > > It is possible that you got hit by the kqemu tsc vs smp problem, i.e.
> > > > passing `notsc' to the guest kernel or forcing qemu onto one cpu
> > > > (cpuset -l 0 qemu ...) may have helped there, sorry I should have thought
> > > > of that earlier...
> > > > 
> > > 
> > > I just tried these suggestions (with the standard qemu-devel) and they
> > > don't seem to do any harm :-P
> > > 
> > ..but they didn't help either?  (i.e. w/o -no-acpi)
> >
> 
> Yes it did.  It boots without -no-apci and with notpc just fine.
> 
You mean notsc, right...?

> > > 
> > > Now I'm thinking about giving the patched qemu-devel another try, since
> > > I've found some workarounds for booting.  I'll see whether I can at least
> > > boot into the installed openSUSE using it.
> > 
> 
> OK, the patched qemu-devel can boot the already installed openSUSE.
> 
> I tried it with and without kernel-kqemu and both worked as long as
> I booted with notpc.
> 
 ..also notsc here? :)

> Can't explain why the installation failed, though.

 OK, thanx,
	Juergen

[Qemu-devel] Re: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD...

[Gary Jennejohn]

On Mon, 2 Mar 2009 00:13:16 +0100
Juergen Lock <nox@jelal.kn-bremen.de> wrote:

> On Sun, Mar 01, 2009 at 06:57:09PM +0100, Gary Jennejohn wrote:
> > Yes it did.  It boots without -no-apci and with notpc just fine.
> > 
> You mean notsc, right...?
> 
> > > > 
> > > > Now I'm thinking about giving the patched qemu-devel another try, since
> > > > I've found some workarounds for booting.  I'll see whether I can at least
> > > > boot into the installed openSUSE using it.
> > > 
> > 
> > OK, the patched qemu-devel can boot the already installed openSUSE.
> > 
> > I tried it with and without kernel-kqemu and both worked as long as
> > I booted with notpc.
> > 
>  ..also notsc here? :)
> 

Yes, I meant notsc everywhere :-P

---
Gary Jennejohn