[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: Dmitry Poletaev
Subject: Re: [Qemu-devel] [QESTION] target-i386/kvm: vmx realization
Date: Fri, 27 May 2016 16:20:12 +0300

Thanks for answer.

I think it should be non zero too. Because of guest state is defined by vmcs 
fields, it is unclear for me, why kvm handle same situation in different way.

I didn't see this script and tests. Unit tests end by timeout (I've increased 
it 15 times, all the same) and kvm script prints almost different traces. 
Anyway, it is nice tools for futher debugging. 

May be you could give some more advises?

Thank you.

26.05.2016, 13:09, "Paolo Bonzini" <address@hidden>:
> 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?
> Thanks,
> Paolo
>>  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]