experimental qemu-devel port update, please test!

[Juergen Lock]

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:
>> > 2007/7/9, Eric Anderson <anderson at freebsd.org>:
>> > > Fatal trap 12: page fault while in kernel mode
>> > > cpuid = 0; apic id = 00
>> > > fault virtual address   = 0x82
>> > > fault code              = supervisor read, page not present
>> > > instruction pointer     = 0x20:0xc0928f00
>> > > stack pointer           = 0x28:0xe57b7a3c
>> > > frame pointer           = 0x28:0xe57b7a50
>> > > code segment            = base 0x0, limit 0xfffff, type 0x1b
>> > >                          = DPL 0, pres 1, def32 1, gran 1
>> > > processor eflags        = interrupt enabled, resume, IOPL = 0
>> > > current process         = 69 (qemu)
>> > >
>> > >
>> > > #9  0xc0928f00 in _vm_map_lock (map=0x1, file=0x0, line=0) at
>> > > /usr/src/sys/vm/vm_map.c:421
>> > > #10 0xc092986d in vm_map_wire (map=0x1, start=677306368,
>> > > end=677310464, flags=1) at /usr/src/sys/vm/vm_map.c:1964
>> >
>> > 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.

	Juergen