Debugging an inconsistent shadow page table

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

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.

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!

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]