On Sat, Nov 3, 2012 at 9:05 PM, Hervé Poussineau <hpous...@reactos.org> wrote: > This commit breaks Windows NT4 boot. > QEMU crashes when NT4 switches from 80x25 to 80x43 resolution.
Does it work with -global apic.vapic=false? This is probably same issue that's bugging Win2k and XP. > > First bad commit is: > > commit 0b57e287138728f72d88b06e69b970c5d745c44a > Author: David Gibson <da...@gibson.dropbear.id.au> > Date: Mon Sep 10 12:30:57 2012 +1000 > > cpu_physical_memory_write_rom() needs to do TB invalidates > cpu_physical_memory_write_rom(), despite the name, can also be used to > write images into RAM - and will often be used that way if the machine > uses load_image_targphys() into RAM addresses. > However, cpu_physical_memory_write_rom(), unlike > cpu_physical_memory_rw() > doesn't invalidate any cached TBs which might be affected by the region > written. > This was breaking reset (under full emu) on the pseries machine - we > loaded > our firmware image into RAM, and while executing it rewrite the code at > the entry point (correctly causing a TB invalidate/refresh). When we > reset the firmware image was reloaded, but the TB from the rewrite was > still active and caused us to get an illegal instruction trap. > This patch fixes the bug by duplicating the tb invalidate code from > cpu_physical_memory_rw() in cpu_physical_memory_write_rom(). > Signed-off-by: David Gibson <da...@gibson.dropbear.id.au> > Signed-off-by: Anthony Liguori <aligu...@us.ibm.com> > > > gdb gives: > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb3584b70 (LWP 22345)] > #0 0x80276a36 in helper_stl_mmu (env=0x80bf9f48, addr=4294836352, val=0, > mmu_idx=-2134925496) > at softmmu_template.h:254 > 254 tlb_addr = env->tlb_table[mmu_idx][index].add_write > (gdb) bt > #0 0x80276a36 in helper_stl_mmu (env=0x80bf9f48, addr=4294836352, val=0, > mmu_idx=-2134925496) > at softmmu_template.h:254 > #1 0xb537aa9e in code_gen_buffer () > #2 0x0005849 in ?? () > #3 0x80af3ce0 in ?? () > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > (gdb) p env > $1 = (struct CPUX86State *) 0x80bf9f48 > (gdb) p index > $2 = 224 > > Command line is > qemu-system-i386 -cpu pentium -hda nt40.qcow2 > KVM is not used. > > Reverting the commit (and fixing the conflict) lets Windows NT4 work again. > > Regards, > > Hervé > >
