[Top][All Lists]

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

Re: [Qemu-devel] [QESTION] target-i386/kvm: vmx realization

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [QESTION] target-i386/kvm: vmx realization
Date: Thu, 26 May 2016 12:09:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

On 26/05/2016 11:55, Dmitry Poletaev wrote:
> kvm_mmu_page_fault goes to nonpaging_page_fault, which don't find page in 
> cache and calls nonpaging_map. nonpaging_map exits after critical section 
> before out_unlock label. For me reaction is normal and looks the same on both 
> platforms, but I think problem may be here deeper.
> After #PF handling kvm enters to guest again and here difference begins. Real 
> machine have new #PF far away from this address, but qemu falls to kvm again 
> with #PF on 0xfe05b.
> This situation repeats infinitely. Qemu vmcs fields after exit to kvm don't 
> have important differencies (on my view) with Intel vmcs.
> Some more info I received after logging qemu's address translation.
> Qemu rises first #PF on first entry to guest (pml4e = 0x3d9fe001 pdpe
> = 0x0). On second entry to guest, after kvm handling, it rise #PF again
> (pml4e = 0x3d9fe021 pdpe = 0x3d9fa027 pde = 0x0). Next entries to guest
> is the same (PF and pml4e = 0x3d9fe021 pdpe = 0x3d9fa027 pde = 0x0).

I think the PDE and PTE should have become non-zero, but I'm not sure.

You can use the kvm_flightrecorder script
(scripts/kvm/kvm_flightrecorder in the QEMU git tree) to find where the
differences start exactly.

You can also compare QEMU and Bochs.

BTW, have you tried running the VMX testcases from kvm-unit-tests.git?



> May be someone know, why it is happens and how I can fix my vmx realization, 
> or where I should look.

reply via email to

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