Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
SIGBUS: "ttbr address size fault", possibly caused by .dtb issue
I've written a small app, designed to run in dom0, which uses the Xen "foreignmemory" interface to read arbitrary pages within a user domain. The call to perform the memory mapping succeeds, and a pointer to the mapped buffer is returned by xenforeignmemory_map(). But I get a SIGBUS as soon as I attempt to access the data in the buffer:

(XEN) traps.c:2508:d0v1 <register values...>
[    62.1234413] Unhandled fault: ttbr address size fault (0x92000000) at 0x0000007fxxxxxxxx
Bus error

Note that the timestamped "Unhandled fault" message is actually from the linux kernel (mm/fault.c). I suspect the "address size fault" occurs because something is telling Xen that 0x7fxxxxxxxx is an invalid (too large) address. Looking in $(RELEASE_DIR)/dts/xen-zcu102.dts, I see the following:
    memory {
        device_type = "memory";
        reg = <0x0 0x0 0x0 0x80000000 0x8 0x0 0x0 0x80000000>;

...which, IIUC, defines 2, 2G memory regions: one at address 0, the other at address 0x800000000. Adding 2G to the start of the upper range gives an end address of 0x880000000, which is significantly below the address of the buffer I'm attempting to access. Accordingly, I tried modifying the memory device entry to increase the sizes from 0x80000000 to 0x8000000000, which should have placed the offending address within both upper and lower ranges, but the error persisted. Is there another DTB file I would need to modify? The one I modified is the one that gets copied to the sd card's boot partition, which I'm assuming is used by the Xen kernel, not Dom0 itself. I just looked at zynqmp-zcu102.dts (under $RELEASE_DIR/components/linux-kernel/xlnx-4.6/arch/arm64/boot/dts) and saw that its memory node looks identical to the one above, so perhaps that's the problem. But if so, it seems odd that mmap() (used by xenforeignmemory_map() to allocate the buffer) would return an address outside the default ranges defined in the kernel's device tree. Isn't the kernel supposed to use the information in the device tree to configure its memory management? As a test, I allocated a buffer with malloc(), and it was placed at 0x3xxxxxxx, well within the configured limits. (Unfortunately, xenforeignmemory_map() doesn't allow you to pass a pointer to the desired buffer the way mmap() does...)
Is the device tree the likely cause of the SIGBUS error? If so, is changing the memory node's "reg" property the right fix, or does the fact that mmap() returns an address above 4G point to a problem elsewhere?
Brett S.

Messages In This Thread
SIGBUS: "ttbr address size fault", possibly caused by .dtb issue - brettstahlman - 10-19-2017, 05:04 PM

Forum Jump:

Users browsing this thread: 1 Guest(s)