Re: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test new patch :)

Juergen,

With your latest patch things are looking pretty good!

- Multiple qemus on a MP FreeBSD amd64 works with kqemu
  enabled for user code.  Some running 64 bit kernels
  (freebsd), some running 32 bit kernels (freebsd and
plan9).

- Nested qemus work! That is, qemu*x86_64 under
qemu*x86_64,
  both with user mode kqemu. A 32 bit 7.0 kernel under it
ran
  fine.  Ideally qemus should nest as long as there is
enough
  memory (a torture test for emulation fidelity).

- As mentioned in another thread netbooting works well
enough
  but you have to use pxeboot from -current and append a
byte
  to it to work around an etherboot tftp bug.

Now the bugs (probably most having to do with qemu/kqemu,
not the freebsd port):

1. kernel mode kqemu seems to cause crashes.  Generally
this
   happens right after the guest freebsd kernel comes up.

2. After the above crash VM reboots automatically but now
it
   can't find the root device so it hangs at the root
   selection prompt.

3. Ocassionally plan9 and (less often FreeBSD) crashes on
   boot.  Looks like a race condition of some sort.  If
they
   boot, there are no further problems traceable to
   qemu/kqemu.

4. "calcru: runtime went backwards from <t1> usec
to <t2> for
   pid <pid> (<cmd>)" is back! Also, ntpd
seems to get very
   confused and after syncing with another clock shifts
   mostly correct time by a few hours.

5. An initial getty gets killed as it "exceeded maximum
CPU limit"
   This could an emulation bug or related to time issues.

Random thoughts:
- If qemu is made scriptable we can automate a lot of
  testing.  For qemu/kqemu and freebsd.

- We need to add a section on qemu in the handbook.
_______________________________________________
freebsd-amd64freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to
"freebsd-amd64-unsubscribefreebsd.org"

On Sun, May 11, 2008 at 12:27:45PM -0700, Bakul Shah wrote:
> Juergen,
> 
> With your latest patch things are looking pretty good!
> 
> - Multiple qemus on a MP FreeBSD amd64 works with
kqemu
>   enabled for user code.  Some running 64 bit kernels
>   (freebsd), some running 32 bit kernels (freebsd and
plan9).
> 
> - Nested qemus work! That is, qemu*x86_64 under
qemu*x86_64,
>   both with user mode kqemu. A 32 bit 7.0 kernel under
it ran
>   fine.  Ideally qemus should nest as long as there is
enough
>   memory (a torture test for emulation fidelity).
> 
> - As mentioned in another thread netbooting works well
enough
>   but you have to use pxeboot from -current and append
a byte
>   to it to work around an etherboot tftp bug.
> 
> Now the bugs (probably most having to do with
qemu/kqemu,
> not the freebsd port):
> 
> 1. kernel mode kqemu seems to cause crashes.  Generally
this
>    happens right after the guest freebsd kernel comes
up.
> 
> 2. After the above crash VM reboots automatically but
now it
>    can't find the root device so it hangs at the root
>    selection prompt.
> 
> 3. Ocassionally plan9 and (less often FreeBSD) crashes
on
>    boot.  Looks like a race condition of some sort.  If
they
>    boot, there are no further problems traceable to
>    qemu/kqemu.
> 
> 4. "calcru: runtime went backwards from <t1>
usec to <t2> for
>    pid <pid> (<cmd>)" is back! Also,
ntpd seems to get very
>    confused and after syncing with another clock
shifts
>    mostly correct time by a few hours.
> 
> 5. An initial getty gets killed as it "exceeded
maximum CPU limit"
>    This could an emulation bug or related to time
issues.
The #5 usually means the thread' kernel stack overflow.

> 
> Random thoughts:
> - If qemu is made scriptable we can automate a lot of
>   testing.  For qemu/kqemu and freebsd.
> 
> - We need to add a section on qemu in the handbook.

On Sun, May 11, 2008 at 12:27:45PM -0700, Bakul Shah wrote:
> Juergen,
> 
> With your latest patch things are looking pretty good!
> 
> - Multiple qemus on a MP FreeBSD amd64 works with
kqemu
>   enabled for user code.  Some running 64 bit kernels
>   (freebsd), some running 32 bit kernels (freebsd and
plan9).
> 
> - Nested qemus work! That is, qemu*x86_64 under
qemu*x86_64,
>   both with user mode kqemu. A 32 bit 7.0 kernel under
it ran
>   fine.  Ideally qemus should nest as long as there is
enough
>   memory (a torture test for emulation fidelity).
> 
> - As mentioned in another thread netbooting works well
enough
>   but you have to use pxeboot from -current and append
a byte
>   to it to work around an etherboot tftp bug.
> 
> Now the bugs (probably most having to do with
qemu/kqemu,
> not the freebsd port):
> 
> 1. kernel mode kqemu seems to cause crashes.  Generally
this
>    happens right after the guest freebsd kernel comes
up.
> 
Yeah I posted one of those on the qemu list,
	http://lists.gnu.org/archive/html/qemu-devel/2
008-05/msg00233.html

 32 bit linux guests seem to work fine tho at least.

> 2. After the above crash VM reboots automatically but
now it
>    can't find the root device so it hangs at the root
>    selection prompt.
> 
 Hmm.

> 3. Ocassionally plan9 and (less often FreeBSD) crashes
on
>    boot.  Looks like a race condition of some sort.  If
they
>    boot, there are no further problems traceable to
>    qemu/kqemu.
> 
 Hmm.

> 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...

>    Also, ntpd seems to get very
>    confused and after syncing with another clock
shifts
>    mostly correct time by a few hours.
> 
 Ouch.

> 5. An initial getty gets killed as it "exceeded
maximum CPU limit"
>    This could an emulation bug or related to time
issues.
> 
> 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?

> - We need to add a section on qemu in the handbook.

 Hmmm... 

	Juergen
_______________________________________________
freebsd-amd64freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to
"freebsd-amd64-unsubscribefreebsd.org"