[Xen-devel] FreeBSD 6.0 on VT-x causes Qemu SEG fault

[Randy Thelen <rthelen@xxxxxxxxxx>]

Folks --

During the boot process of FreeBSD 6.0 on Xen 3.0 w/ VT-x hardware,  
I'm experiencing a situation where Qemu gets an exception and dies  
leaving the FreeBSD domain blocked.
Here is some relevant data I've collected on the Qemu side of the  
fault (as opposed to anything on the FreeBSD side).  I can't make  
heads or tails out of it, but I think there's enough here for someone  
to give me directions on where next to look.
(gdb) bt
#0  breakyourboneshere ()
    at /home/goodson/xen-3.0-testing/tools/ioemu/exec.c:391
#1  0x0000000000408682 in cpu_physical_memory_rw (addr=3228123076,
    buf=0x2abf96849020 <Address 0x2abf96849020 out of bounds>, len=4,
    is_write=1) at /home/goodson/xen-3.0-testing/tools/ioemu/exec.c:446
#2  0x000000000043d722 in cpu_ioreq_move (env=Variable "env" is not  
available.) at helper2.c:274
#3  0x000000000043d953 in cpu_handle_ioreq (env=0x1831c40) at  
helper2.c:431
#4  0x000000000043dbf1 in main_loop () at helper2.c:511
#5  0x0000000000407c90 in main (argc=Variable "argc" is not available.)
    at /home/goodson/xen-3.0-testing/tools/ioemu/vl.c:3447

First, "breakyourboneshere()" is a routine I wrote that I could put a  
break point on before the seg fault happens.  It's called like:
                addr1 = (pd & TARGET_PAGE_MASK) + (addr &  
~TARGET_PAGE_MASK);
                /* RAM case */
                ptr = phys_ram_base + addr1;
                { extern void *shared_page;
                  unsigned long xyz = (unsigned long) ptr,
                    abc = (unsigned long) shared_page;
                  if ((xyz - abc) == 0xb0694fc4) {
                    breakyourboneshere();
                  }
                }

                memcpy(ptr, buf, l);

My colleague installed some tracing and found that the ioreq that has  
caused this grief looks like:
(gdb) p/x ioreq_buffer[5]
$5 = {addr = 0xc0693fc4, size = 0x4, count = 0x1, u = {data = 0x56f50,
    pdata = 0x56f50}, state = 0x1, pdata_valid = 0x0, dir = 0x0, df  
= 0x0,
  type = 0x1, io_count = 0x6714f}

It's always the same request.  What I can't figure out is what the  
guest domain code thinks it's doing.
Anybody got any ideas?  Any tests you'd like me to perform?  Running  
tests takes on the order of a few minutes.
What I'd like to know is where in FreeBSD we are, exactly.  What I  
can say is that in the guest domain we have:
1) Entered grub
2) booted the FreeBSD loader (btx, btxldr for those who know about  
these things)
3) "loader" (?) brought up a boot screen of its own (it's Forth code,  
if you must know)
4) The timer on the boot screen timed out and immediately after that  
the above iorequest arrived and causes Qemu to seg fault.
Is there any way to get the guest domain context from within Qemu?   
I'd like to know the guest domain register set for the code issuing  
this ioreq.
Any tips or ideas will be appreciated.

-- Randy

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel