From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: Debugging an inconsistent shadow page table Date: Sun, 26 Apr 2009 13:11:40 +0200 Message-ID: <49F4416C.4090204@web.de> References: <49F2E79A.6070602@web.de> <49F43846.40807@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9AAAE5B416CDD45C2244E126" Cc: kvm-devel To: Avi Kivity Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:56235 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750898AbZDZLLr (ORCPT ); Sun, 26 Apr 2009 07:11:47 -0400 In-Reply-To: <49F43846.40807@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9AAAE5B416CDD45C2244E126 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > Jan Kiszka wrote: >> Hi, >> >> turning on MMU_DEBUG and AUDIT in arch/x86/kvm/mmu.c (and fixing a bui= ld >> 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. >> =20 >=20 > 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. >=20 > But the message is self-contradictory. Level 4 PTEs map 0.5TB each, an= d > the gva mentioned isn't 0.5TB aligned. >=20 >> 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 slipp= ed >> in, host and guest see different page contents and virtio-net stops to= >> work. Very strange, but fortunately easily reproducible here. Any hint= s >> or debugging suggestions welcome! >> =20 >=20 > What type of inconsistency? pfn or flags? >=20 The former. Here is a before-after walk of the shadow and the host page table (format: () ): [good] gva=3Dffff88001ef22000: 000000002fc57000 -> 000000002fc57880 (000000003d119027) -> 000000003d119000 (000000005d9bf027) -> 000000005d9bf7b8 (000000003d159027) -> 000000003d159910 (000000002fbce063) -> 000000002fbce000 =3D 01 00 07 00 hva=3D00007f4665cac000: 00000000701f4000 -> 00000000701f47f0 (000000005d925067) -> 000000005d9258c8 (000000005d8c5067) -> 000000005d8c5970 (000000003d2b4067) -> 000000003d2b4560 (800000002fbce067) -> 800000002fbce000 =3D 01 00 07 00 [bad] gva=3Dffff88001ef22000: 000000002fc57000 -> 000000002fc57880 (000000003d119027) -> 000000003d119000 (000000005d9bf027) -> 000000005d9bf7b8 (000000003d159027) -> 000000003d159910 (000000002fbce063) -> 000000002fbce000 =3D 01 00 0a 00 hva=3D00007f4665cac000: 00000000701f4000 -> 00000000701f47f0 (000000005d925067) -> 000000005d9258c8 (000000005d8c5067) -> 000000005d8c5970 (000000003d2b4067) -> 000000003d2b4560 (800000006576d067) -> 800000006576d000 =3D 01 00 10 00 That raise a question for a kvm-mmu newbie like me: If a page of the qemu process gets pushed around (here likely due to fork()->exec(smbd)->COW), how will kvm's shadow table catch up? Via MMU_NOTIFIER? I'm on a 2.6.25 kernel, and that means without CONFIG_MMU_NOTIFIER. So far I assumed that kernels without this feature do not work optimally, but they won't break my guests... Jan --------------enig9AAAE5B416CDD45C2244E126 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkn0QXAACgkQniDOoMHTA+k9fACcDi7GdOusDXTrT0eJBPRy3oYf KmsAn2p88wq0yDgld2ueEkN0E9Eq3c7z =5ot3 -----END PGP SIGNATURE----- --------------enig9AAAE5B416CDD45C2244E126--