On 5/24/20 6:12 AM, Alexander Bulekov wrote: > Public bug reported: > > For me, this takes close to 3 minutes at 100% CPU: > echo "outl 0x518 0x9596ffff" | ./i386-softmmu/qemu-system-i386 -M q35 -m 32 > -nographic -accel qtest -monitor none -serial none -qtest stdio > > #0 phys_page_find (d=0x606000035d80, addr=136728041144404) at /exec.c:338 > #1 address_space_lookup_region (d=0x606000035d80, addr=136728041144404, > resolve_subpage=true) at /exec.c:363 > #2 address_space_translate_internal (d=0x606000035d80, addr=136728041144404, > xlat=0x7fff1fc0d070, plen=0x7fff1fc0d090, resolve_subpage=true) at /exec.c:382 > #3 flatview_do_translate (fv=0x606000035d20, addr=136728041144404, > xlat=0x7fff1fc0d070, plen_out=0x7fff1fc0d090, page_mask_out=0x0, > is_write=true, is_mmio=true, target_as=0x7fff1fc0ce10, attrs=...) > pment/qemu/exec.c:520 > #4 flatview_translate (fv=0x606000035d20, addr=136728041144404, > xlat=0x7fff1fc0d070, plen=0x7fff1fc0d090, is_write=true, attrs=...) at > /exec.c:586 > #5 flatview_write_continue (fv=0x606000035d20, addr=136728041144404, > attrs=..., ptr=0x7fff1fc0d660, len=172, addr1=136728041144400, l=172, > mr=0x557fd54e77e0 <io_mem_unassigned>) > pment/qemu/exec.c:3160 > #6 flatview_write (fv=0x606000035d20, addr=136728041144064, attrs=..., > buf=0x7fff1fc0d660, len=512) at /exec.c:3177 > #7 address_space_write (as=0x557fd54e7a00 <address_space_memory>, > addr=136728041144064, attrs=..., buf=0x7fff1fc0d660, len=512) at /exec.c:3271 > #8 dma_memory_set (as=0x557fd54e7a00 <address_space_memory>, > addr=136728041144064, c=0 '\000', len=1378422272) at /dma-helpers.c:31 > #9 fw_cfg_dma_transfer (s=0x61a000001e80) at /hw/nvram/fw_cfg.c:400 > #10 fw_cfg_dma_mem_write (opaque=0x61a000001e80, addr=4, value=4294940309, > size=4) at /hw/nvram/fw_cfg.c:467 > #11 memory_region_write_accessor (mr=0x61a000002200, addr=4, > value=0x7fff1fc0e3d0, size=4, shift=0, mask=4294967295, attrs=...) at > /memory.c:483 > #12 access_with_adjusted_size (addr=4, value=0x7fff1fc0e3d0, size=4, > access_size_min=1, access_size_max=8, access_fn=0x557fd2288c80 > <memory_region_write_accessor>, mr=0x61a000002200, attrs=...) > pment/qemu/memory.c:539 > #13 memory_region_dispatch_write (mr=0x61a000002200, addr=4, data=4294940309, > op=MO_32, attrs=...) at /memory.c:1476 > #14 flatview_write_continue (fv=0x606000035f00, addr=1304, attrs=..., > ptr=0x7fff1fc0ec40, len=4, addr1=4, l=4, mr=0x61a000002200) at /exec.c:3137 > #15 flatview_write (fv=0x606000035f00, addr=1304, attrs=..., > buf=0x7fff1fc0ec40, len=4) at /exec.c:3177 > #16 address_space_write (as=0x557fd54e7bc0 <address_space_io>, addr=1304, > attrs=..., buf=0x7fff1fc0ec40, len=4) at /exec.c:3271 > > > It looks like fw_cfg_dma_transfer gets the address(136728041144064) and > length(1378422272) for the read from the value provided as input 4294940309 > (0xFFFF9695) which lands in pcbios. Should there be any limits on the length > of guest-memory that fw_cfg should populate?
It looks to me a normal behavior for a DMA device. DMA devices have a different address space view than the CPUs. Also note the fw_cfg is a generic device, not restricted to the x86 arch. Maybe this function could use dma_memory_valid() to skip unassigned regions?
