[Qemu-devel] [Bug 1068044] Re: regression: booting winxp installation iso makes qemu-system-i386 crash in latest git

[Bernhard Übelacker]

Got fixed before release v1.3.0 in this commit:

commit 5c61afec86e5b2597b19b4657edc404fd76e6eb9
Author: Jan Kiszka <address@hidden>
Date:   Sun Nov 4 09:16:55 2012 +0100

    kvmvapic: Fix TB invalidation after instruction patching
    
    Since 0b57e287, cpu_memory_rw_debug already triggers a TB invalidation.
    As it doesn't (and cannot) set is_cpu_write_access=1 but "consumes" the
    currently executed TB, the tb_invalidate_phys_page_range call from
    patch_instruction didn't work anymore.
    
    Fix this by open-coding the required bits to restore the CPU state from
    the current TB position before patching and resume execution on the
    patched instruction afterward.
    
    Signed-off-by: Jan Kiszka <address@hidden>
    Tested-by: Hervé Poussineau <address@hidden>
    Signed-off-by: Blue Swirl <address@hidden>


** Changed in: qemu
       Status: New => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1068044

Title:
  regression: booting winxp installation iso makes qemu-system-i386
  crash in latest git

Status in QEMU:
  Fix Released

Bug description:
  Booting a windows xp sp3 installation cd with current git results on arm host 
and x86 host in a SIGSEGV
  between loading the drivers for some hardware and the selection for 
installation, repair or the recovery console.

  
  Bisecting leads to this commit:
  0b57e287138728f72d88b06e69b970c5d745c44a is the first bad commit
  commit 0b57e287138728f72d88b06e69b970c5d745c44a
  Author: David Gibson <address@hidden>
  Date:   Mon Sep 10 12:30:57 2012 +1000

      cpu_physical_memory_write_rom() needs to do TB invalidates
  ...
  :100644 100644 c0fbd5b149fd01929410e970b3e8f4a9b9b9700c 
f22e9e69519177fa50de3a966b35f8c8faa4a7d0 M      exec.c

  
  This commit was later changed to a call to invalidate_and_set_dirty.

  By disabling this call to invalidate_and_set_dirty in exec.c:3536 the machine 
can boot successfully to
  the selection screen.

  
  - Got current git
  - ./configure --target-list='i386-softmmu' --disable-werror --static 
--disable-strip --enable-debug --enable-debug-tcg
  - gdb --args 
/home/qemu/qemu-data/qemu-git_2012-10-17_origin/qemu-git/qemu/i386-softmmu/qemu-system-i386
 -monitor stdio -vnc :0 -cdrom 
/home/qemu/qemu-data/machines/winxp/winxp-homepro-sp3-setup.iso

  
  On ARM (Feroceon 88F6281 rev 1 (v5l), running a Debian Wheezy chroot):
  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0x42a012e0 (LWP 19506)]
  0x0034d354 in helper_stl_mmu (env=0x0, addr=0, val=1553085696, 
mmu_idx=1553085696)
      at 
/home/qemu/qemu-data/qemu-git_2012-10-17_origin/qemu-git/qemu/softmmu_template.h:254
  254         tlb_addr = env->tlb_table[mmu_idx][index].addr_write;
  (gdb) bt
  #0  0x0034d354 in helper_stl_mmu (env=0x0, addr=0, val=1553085696, 
mmu_idx=1553085696)
      at 
/home/qemu/qemu-data/qemu-git_2012-10-17_origin/qemu-git/qemu/softmmu_template.h:254
  #1  0x40362074 in ?? ()
  #2  0x40362074 in ?? ()
  Backtrace stopped: previous frame identical to this frame (corrupt stack?)
  (gdb) 

  
  Later found this behaviour also on x86 (AMD Athlon 64 X2 running Debian 
Squeeze):
  (gdb) handle SIGUSR1 noprint nostop
  Signal        Stop      Print   Pass to program Description
  SIGUSR1       No        No      Yes             User defined signal 1
  (gdb) run
  Starting program: 
/home/bernhard/data/emu/pc/qemu/emu/qemu-git_2012-10-17_origin/qemu-git/qemu/i386-softmmu/qemu-system-i386
 -monitor stdio -vnc :0 -cdrom ../machines/winxp/winxp-homepro-sp3-setup.iso
  [Thread debugging using libthread_db enabled]
  [New Thread 0xb4dfcb70 (LWP 32438)]
  [New Thread 0xb45fcb70 (LWP 32439)]
  QEMU 1.2.50 monitor - type 'help' for more information
  (qemu) [New Thread 0xab365b70 (LWP 32440)]

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0xb45fcb70 (LWP 32439)]
  0x082463b8 in tlb_set_page (env=0x8bab658, vaddr=4294836224, 
paddr=4276092928, prot=7, mmu_idx=146454104, size=4096)
      at 
/home/bernhard/data/emu/pc/qemu/emu/qemu-git_2012-10-17_origin/qemu-git/qemu/cputlb.c:281
  281         env->iotlb[mmu_idx][index] = iotlb - vaddr;
  (gdb) bt
  #0  0x082463b8 in tlb_set_page (env=0x8bab658, vaddr=4294836224, 
paddr=4276092928, prot=7, mmu_idx=146454104, size=4096)
      at 
/home/bernhard/data/emu/pc/qemu/emu/qemu-git_2012-10-17_origin/qemu-git/qemu/cputlb.c:281
  #1  0x082ed6f2 in cpu_x86_handle_mmu_fault (env=0x8bab658, addr=4294836352, 
is_write1=1, mmu_idx=146454104)
      at 
/home/bernhard/data/emu/pc/qemu/emu/qemu-git_2012-10-17_origin/qemu-git/qemu/target-i386/helper.c:847
  #2  0x082f9b09 in tlb_fill (env=0x8bab658, addr=4294836352, is_write=1, 
mmu_idx=146454104, retaddr=3056035390)
      at 
/home/bernhard/data/emu/pc/qemu/emu/qemu-git_2012-10-17_origin/qemu-git/qemu/target-i386/mem_helper.c:141
  #3  0x082f8ed1 in helper_stl_mmu (env=0x8bab658, addr=4294836352, val=0, 
mmu_idx=146454104)
      at 
/home/bernhard/data/emu/pc/qemu/emu/qemu-git_2012-10-17_origin/qemu-git/qemu/softmmu_template.h:291
  #4  0xb627663f in code_gen_buffer ()
  #5  0x00000000 in ?? ()
  (gdb)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1068044/+subscriptions