qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: Main loop


From: malc
Subject: [Qemu-devel] Re: Main loop
Date: Mon, 28 Sep 2009 13:42:34 +0400 (MSD)

On Mon, 28 Sep 2009, Juan Quintela wrote:

> malc <address@hidden> wrote:
> > At http://repo.or.cz/w/qemu/malc.git?a=shortlog;h=refs/heads/mtloop you
> > can find the branch which refactors main execution loop somewhat, effects
> > include:
> >
> > a. Host alarm timers are gone
> > b. IO thread is replaced (now Windows is supported too)
> >
> > I have no means of testing the KVM/Xen bits (both are likely to be broken
> > by this), and since testing was only done on Linux/X86-64[1],PPC and 
> > Windows/i386 chances are good that something might be not so great in
> > BSD/Solairs/MacOS X lands.
> 
> No cookie:
> It don't work in kvm mode.

Didn't i say that i have no means of testing it? Even x86 box yields:

~$ uname -a
Linux laptop 2.6.31 #7 SMP PREEMPT Sun Sep 13 10:59:44 MSD 2009 x86_64 AMD 
Athlon(tm)64 X2 Dual Core Processor  3800+ AuthenticAMD GNU/Linux
~$ egrep '^flags.*(vmx|svm)' /proc/cpuinfo 
~$

Help is needed with that.

> address@hidden ~]# /scratch/qemu/x86_64-softmmu/qemu-system-x86_64 -M pc -m 
> 512 -smp 1 -name test -drive file=/scratch/tmp/f11b.img -net 
> nic,macaddr=54:52:00:53:7e:5b,vlan=0,model=virtio -net 
> tap,script=/etc/kvm-ifup,vlan=0,ifname=vnet1,downscript=no --monitor stdio 
> --serial telnet:0:5553,server --virtioconsole telnet:0:5554,server 
> --enable-kvm -usbdevice tablet -vnc :1
> QEMU waiting for connection on: telnet:0.0.0.0:5553,server
> QEMU waiting for connection on: telnet:0.0.0.0:5554,server
> QEMU 0.11.50 monitor - type 'help' for more information
> (qemu) exec_thread_loop: sem_wait/halt: Interrupted system call
> Aborted
> 
> It is not able to finish boot.

And yet you still enable kvm.. sigh..

> 
> Doing a loadvm of a guest, just load the data, it don't run at all.
> 
> > Apart from obvious KVM bits, other things were not implemented (yet) 
> > either: proper VM stop/resume, GDB, etc.

And somehow the above failed to impress and suggest that loadvm wouldn't work?

[..snip..]

-- 
mailto:address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]