experimental qemu-devel port update, please test!

Craig Boston craig at yekse.gank.org
Thu Jul 12 21:30:14 UTC 2007


On Mon, Jul 09, 2007 at 11:49:33PM +0200, Juergen Lock wrote:
> In article <3bbf2fe10707091218p713b7e3ela2833eec0ba2df13 at mail.gmail.com> you write:
> >2007/7/9, Doug Rabson <dfr at rabson.org>:
> >> On Monday 09 July 2007, Attilio Rao wrote:
> >> > Please also note that stack here seems highly corrupted since values
> >> > passed to _vm_map_lock are not possible (or there is something
> >> > serious going on with them).
> >>
> >> I had this exact same crash when attempting to use kqemu on a recent
> >> current. It appears as if the value it got for curproc was bad. Is
> >> kqemu messing with the kernel's %fs value perhaps?
> >
> >I don't know about kqemu, but in this case I would expect sorta of
> >larger corruption due to the wider pcpu accesses done through %fs.
> 
> Actually it might use %fs while in the monitor (for running guest code),
> but if I read the code right it doesn't let host kernel code run while
> in there (it catches interrupts and leaves the monitor, restoring state,
> to run them.)
> 
>  Also, it still seems to be in kqemu_init when this happened, and I
> don't think it enters the monitor from in there already.

I took a look at it last night and found some very confusing results.
It's definitely happening during the KQEMU_INIT ioctl.  The stack is not
being corrupted, %fs has not been tampered with, and 0x1 is indeed
being passed to vm_map_wire.

For some reason when the ioctl is issued, curproc points to a totally
bogus proc structure.  curthread seems to be sane as far as I can tell,
but the process it claims to belong to is full of junk.

Here is a dump of some miscellaneous values from curthread (labeled td
below) and curproc (cp) from a couple places along the call stack:

===== kqemu_ioctl (KQEMU_GET_VERSION) =====
%ds in kqemu_ioctl: 0x28
%fs in kqemu_ioctl: 0x8
td: 0xc7232400
td->td_proc: 0xc556e2ac
td->td_tid: 100141
td->td_wmesg: (null)
td->td_name: 
td->td_sleepqueue: 0xc4aa8b20
td->td_flags: 16777216
td->td_oncpu: 0
td->td_ucred: 0xc5f92b00
td->td_runtime: 493921239146
cp: 0xc556e2ac
cp->p_vmspace: 0x1
cp->p_pid: 1
cp->p_comm: 
cp->p_fd: 0
cp->p_pptr: 0
cp->p_magic: 0
cp->p_pgrp: 0
cp->p_numthreads: 2147483647

===== kqemu_ioctl (KQEMU_INIT) =====
%ds in kqemu_ioctl: 0x28
%fs in kqemu_ioctl: 0x8
td: 0xc7232400
td->td_proc: 0xc556e2ac
td->td_tid: 100141
td->td_wmesg: (null)
td->td_name: 
td->td_sleepqueue: 0xc4aa8b20
td->td_flags: 16777216
td->td_oncpu: 0
td->td_ucred: 0xc5f92b00
td->td_runtime: 498216206442
cp: 0xc556e2ac
cp->p_vmspace: 0x1
cp->p_pid: 1
cp->p_comm: 
cp->p_fd: 0
cp->p_pptr: 0
cp->p_magic: 0
cp->p_pgrp: 0
cp->p_numthreads: 2147483647

===== kqemu_lock_user_page (a result of previous ioctl, it's still above
us in the call stack) =====
%ds in kqemu_lock_user_page: 0x28
%fs in kqemu_lock_user_page: 0x8
td: 0xc7232400
td->td_proc: 0xc556e2ac
td->td_tid: 100141
td->td_wmesg: (null)
td->td_name: 
td->td_sleepqueue: 0xc4aa8b20
td->td_flags: 16910337
td->td_oncpu: 0
td->td_ucred: 0xc5f92b00
td->td_runtime: 511101108330
cp: 0xc556e2ac
cp->p_vmspace: 0x1
cp->p_pid: 1
cp->p_comm: 
cp->p_fd: 0
cp->p_pptr: 0
cp->p_magic: 0
cp->p_pgrp: 0
cp->p_numthreads: 2147483647

A few things to note.  First is that the initial dump from kqemu_ioctl
shows the bogus process too, and this is well before kqemu has a chance
to do much of anything, much less start mucking around with registers
and VM mappings.

The thread pointer does seem to be valid.  Note that td_runtime
increases a little between the first two ioctl calls, and then more by
the time it gets to kqemu_lock_user_page.

curproc (td_proc) changes between each invocation of qemu, so despite
the fact that p_pid == 1, I'm certain that it's not really init.

Other than that I'm not really sure why curproc is so screwed up.
Surely it has to be specific to the kqemu module otherwise I can't see
how the kernel could function at all...

Craig
_______________________________________________
freebsd-ports at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"


More information about the freebsd-emulation mailing list