Re: Kernel Oops with kvm 66 running WinXP

Izik Eidus
2008-05-05T07:04:50Z

> Avi Kivity wrote:
>> Izik Eidus wrote:
>>> Michal Ludvig wrote:
>>>
>>>> Avi Kivity wrote:
>>>>
>>>>> Avi Kivity wrote:
>>>>>
>>>>>> Michal Ludvig wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I've experienced a kernel Oops on 2.6.24 with kvm 66 on AMD in
>>>>>>> 64bit mode while starting up WinXP:
>>>>>>>
>>>>>>> The host is still alive but the XP guest is locked up in a boot
>>>>>>> screen.
>>>>>>>
>>>> Hi again, just wanted to let you know that I still get this Oops
>>>> with kvm-68. It comes a bit later, not during the boot but after the
>>>> XP desktop comes up. As there were some changes in
>>>> kernel/x86_emulate.c the patch you provided for kvm-66 can't be
>>>> applied anymore.
>>>>
>>>> loaded kvm module (kvm-68)
>>>> kvm: emulating exchange as write
>>>> Unable to handle kernel NULL pointer dereference at 0000000000000000
>>>> RIP:
>>>> [<ffffffff88373b4a>] :kvm:x86_emulate_insn+0x3fa/0x4240
>>>> PGD 3145e067 PUD 409b9067 PMD 0
>>>> Oops: 0002 [1] SMP
>>>> CPU 0
>>>> Modules linked in: kvm_amd kvm reiserfs tun bridge llc nfsd lockd
>>>> nfs_acl auth_rpcgss sunrpc exportfs iptable_filter ip_tables autofs4
>>>> snd_pcm_oss snd_mixer_oss w83627ehf snd_seq snd_seq_device hwmon_vid
>>>> ip6table_filter ip6_tables x_tables af_packet ipv6 fuse ext2 loop
>>>> snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc sr_mod
>>>> k8temp hwmon i2c_nforce2 button i2c_core cdrom forcedeth sg floppy
>>>> linear ehci_hcd ohci_hcd sd_mod usbcore dm_snapshot edd dm_mod fan
>>>> sata_nv pata_amd libata scsi_mod thermal processor
>>>> Pid: 14776, comm: qemu-system-x86 Not tainted 2.6.24-mludvig #1
>>>> RIP: 0010:[<ffffffff88373b4a>] [<ffffffff88373b4a>]
>>>> :kvm:x86_emulate_insn+0x3fa/0x4240
>>>> RSP: 0018:ffff81007d52fc18 EFLAGS: 00010246
>>>> RAX: 000000008001003b RBX: 0000000000000000 RCX: 0000000000000000
>>>> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff810079c5c000
>>>> RBP: ffff810079c5d320 R08: ffff810079c5d3c0 R09: 0000000000000006
>>>> R10: 0000000000000002 R11: 0000000000000000 R12: ffff810079c5d368
>>>> R13: ffff810079c5d3c0 R14: ffffffff8838ab20 R15: 00000000019d1353
>>>> FS: 0000000040800950(0063) GS:ffffffff8053e000(0000)
>>>> knlGS:0000000000000000
>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>>> CR2: 0000000000000000 CR3: 000000007985a000 CR4: 00000000000006e0
>>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>>> Process qemu-system-x86 (pid: 14776, threadinfo ffff81007d52e000,
>>>> task ffff81003f4e6780)
>>>> Stack: 000000007d52fc74 0000000011fda618 000000000f399068
>>>> ffff810079c5d3c0
>>>> ffff81007d52fc94 ffffffff88368ae0 0000000000000000 ffff810079c5c000
>>>> ffff810079c5d320 0000000000000000 0000000000000000 0000000000000000
>>>> Call Trace:
>>>> [<ffffffff88368ae0>] :kvm:seg_desct_to_kvm_desct+0x40/0xb0
>>>>
>>>
>>> ok, if we are here it mean windows did task switch,
>>> and if windows did task switch it mean something was probably wrong
>>> before.
>>>
>>>
>>
>> We need to fix the oops regardless.
>>
>>
>
> Oh, I think that's just garbage on the stack. Actual oops is in
> x86_emulate_insn.
>
i saw that the opss was in x86_emulate_insn, you think that seg_desct_to_kvm_desct never got called?
(i would expect to see more traces before this function such as task_switch()...

--
woof.