This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] FreeBSD 6.0 on VT-x causes Qemu SEG fault
From: Randy Thelen <rthelen@xxxxxxxxxx>
Date: Tue, 6 Jun 2006 17:07:56 -0700
Delivery-date: Tue, 06 Jun 2006 17:08:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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) {

                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

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] FreeBSD 6.0 on VT-x causes Qemu SEG fault, Randy Thelen <=