qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Windows NT4 regression due to 0b57e287 ("cpu_physical_m


From: Blue Swirl
Subject: Re: [Qemu-devel] Windows NT4 regression due to 0b57e287 ("cpu_physical_memory_write_rom() needs to do TB invalidates")
Date: Sat, 3 Nov 2012 21:15:28 +0000

On Sat, Nov 3, 2012 at 9:05 PM, Hervé Poussineau <address@hidden> 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 <address@hidden>
> 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 <address@hidden>
>    Signed-off-by: Anthony Liguori <address@hidden>
>
>
> 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é
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]