On Tue, Sep 03, 2019 at 05:50:56PM +0100, Peter Maydell wrote:
> Do you have a backtrace of QEMU from the segfault? I'm having trouble
> thinking of what the situation is when we'd try to invoke the
> read handler on io_mem_notdirty...

Using tcg-next 
https://github.com/rth7680/qemu/commit/c25c283df0f08582df29f1d5d7be1516b851532d.

#0  0x0000000000000000 in  ()
#1  0x000055a694329099 in memory_region_read_with_attrs_accessor 
(mr=0x55a69503c6c0 <io_mem_notdirty>, addr=3874654208, value=0x7fdac32c40e8, 
size=4, shift=0, mask=4294967295, attrs=...)
    at /home/tony/dev/qemu/memory.c:461
#2  0x000055a6943293fd in access_with_adjusted_size (addr=3874654208, 
value=0x7fdac32c40e8, size=4, access_size_min=1, access_size_max=8, access_fn=
    0x55a69432903d <memory_region_read_with_attrs_accessor>, mr=0x55a69503c6c0 
<io_mem_notdirty>, attrs=...) at /home/tony/dev/qemu/memory.c:559
#3  0x000055a69432c239 in memory_region_dispatch_read1 (mr=0x55a69503c6c0 
<io_mem_notdirty>, addr=3874654208, pval=0x7fdac32c40e8, size=4, attrs=...) at 
/home/tony/dev/qemu/memory.c:1429
#4  0x000055a69432c2c9 in memory_region_dispatch_read (mr=0x55a69503c6c0 
<io_mem_notdirty>, addr=3874654208, pval=0x7fdac32c40e8, op=MO_32, attrs=...) 
at /home/tony/dev/qemu/memory.c:1451
#5  0x000055a694341e4f in io_readx (env=0x55a695942da0, iotl=0x7fdabcdee440, 
mmu_idx=2, addr=3298570569728, retaddr=140577648555520, 
access_type=MMU_DATA_LOAD, op=MO_32)
    at /home/tony/dev/qemu/accel/tcg/cputlb.c:923
#6  0x000055a69434493e in full_be_ldul_mmu (full_load=0x55a69434458a 
<full_be_ldul_mmu>, code_read=false, op=MO_BEUL, retaddr=140577648555520, 
oi=162, addr=3298570569728, env=0x55a695942da0)
    at /home/tony/dev/qemu/accel/tcg/cputlb.c:1346
#7  0x000055a69434493e in full_be_ldul_mmu (env=0x55a695942da0, 
addr=3298570569728, oi=162, retaddr=140577648555520) at 
/home/tony/dev/qemu/accel/tcg/cputlb.c:1469
#8  0x000055a694344bd5 in helper_be_ldul_mmu (env=0x55a695942da0, 
addr=3298570569728, oi=162, retaddr=140577648555520) at 
/home/tony/dev/qemu/accel/tcg/cputlb.c:1476
#9  0x00007fdac8ce3639 in  ()
#10 0x0000000004000000 in  ()
#11 0x00007fdabc000a10 in  ()
#12 0x00007fdac32c42a0 in  ()
#13 0x000055a6942d8795 in tcg_temp_free_internal (ts=0x7fdabc0652e0)
    at /home/tony/dev/qemu/tcg/tcg.c:1330

In frame 5 iotlbentry->addr is 18446740779013636097. Perhaps not a sane value?

Defines in target/sparc/cpu-params.h and include/exec/cpu-all.h:
TARGET_PAGE_BITS 13
TARGET_PAGE_SIZE (1 << TARGET_PAGE_BITS)
TARGET_PAGE_MASK ~(TARGET_PAGE_SIZE - 1)

iotlb_to_section resolves (iotlbentry->addr & ~TARGET_PAGE_MASK) to 1,
which is io_mem_notdirty.

(gdb) frame 5
#5  0x000055a694341e4f inv=0x55a695942da0, iotlbentry=0x7fdabcdee440, 
mmu_idx=2, 
    addr=3298570569728, retaddr=140577648555520, access_type=MMU_DATA_LOAD, 
op=MO_32)
    at /home/tony/dev/qemu/accel/tcg/cputlb.c:923
(gdb) print iotlbentry->addr
$1 = 18446740779013636097
(gdb) print iotlbentry->attrs
$2 = {unspecified = 0, secure = 0, user = 0, requester_id = 0, byte_swap = 1, 
  target_tlb_bit0 = 0, target_tlb_bit1 = 0, target_tlb_bit2 = 0}
(gdb) print cpu->cpu_ases[0]->memory_dispatch->map.sections[1]
$3 = {mr = 0x55a69503c6c0 <io_mem_notdirty>, fv = 0x7fdabc86ca00, 
offset_within_region = 0, 
  size = 0x00000000000000010000000000000000, offset_within_address_space = 0, 
  readonly = false, nonvolatile = false}

Watching sun4u Solaris 10 boot messages, it occurs when sunhme PCI device is
configured.

Reply via email to