[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Bug 1068044] Re: regression: booting winxp installation is
From: |
Bernhard Übelacker |
Subject: |
[Qemu-devel] [Bug 1068044] Re: regression: booting winxp installation iso makes qemu-system-i386 crash in latest git |
Date: |
Sat, 09 Aug 2014 13:43:27 -0000 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-devel] [Bug 1068044] Re: regression: booting winxp installation iso makes qemu-system-i386 crash in latest git,
Bernhard Übelacker <=