Re: Debugging an inconsistent shadow page table

[Avi Kivity <avi@redhat.com>]

Jan Kiszka wrote:
> Hi,
>
> turning on MMU_DEBUG and AUDIT in arch/x86/kvm/mmu.c (and fixing a build
> error, patch will follow) I got this (and then a #GP :( - patch will
> follow):
>
> ...
> kvm_mmu_get_page: looking gfn 0 role f0120
> kvm_mmu_get_page: found
> kvm_mmu_get_page: looking gfn 0 role f0220
> kvm_mmu_get_page: found
> kvm_mmu_get_page: looking gfn 0 role f0320
> kvm_mmu_get_page: found
> kvm_mmu_get_page: looking gfn e1f role e0044
> kvm_mmu_get_page: adding gfn e1f role e0044
> rmap_write_protect: spte ffff8100660a60f8 7ca98067
> paging64_page_fault: addr 100105 err 19
> audit_write_protection: (pre page fault) shadow page has writable mappings: gfn e1f role e0044
> audit: (pre page fault) nontrapping pte in nonleaf level: levels 4 gva 8000000000 level 4 pte 0
>
> Is the last message indicating a problem? I get it very early during
> guest boot. oos_shadow is disabled.
>   

Yes.  It means the guest will receive a page fault if is accesses 
anything this pte points to.  Theoretically we could have made this 
work, but we never did.

But the message is self-contradictory.  Level 4 PTEs map 0.5TB each, and 
the gva mentioned isn't 0.5TB aligned.

> I'm currently trying to understand an obvious inconsistency in the pte
> describing a page of the virtio-net rx ring. On some guests with some
> qemu (upstream) command lines I can trigger this with '-smb /some/path'
> and then doing smbclient -L in the guest. Once the inconsistency slipped
> in, host and guest see different page contents and virtio-net stops to
> work. Very strange, but fortunately easily reproducible here. Any hints
> or debugging suggestions welcome!
>   

What type of inconsistency? pfn or flags?

-- 
error compiling committee.c: too many arguments to function