On 12/07/2009 10:51 PM, Marcelo Tosatti wrote:
The BAD_POOL_HEADER BSOD happens at address 0xFFFFF8A000DDD000 (complaining it contains "000000", Arg4). Walking the pagetables takes to 0x18996 as the pte page: (qemu) xp 0x18996ee8 (vaddr 0xFFFFF8A000DDD000) 0000000018996ee8: 0x153c9963 (qemu) xp 0x18996ef0 (vaddr 0xFFFFF8A000DDE000) 0000000018996ef0: 0x1528a963 qemu-system-x86-13667 [007] 425860.260987: kvm_mmu_pte_write: sp->gfn 18996 (offset=ef0) gfn 15f11 invlpg=1 qemu-system-x86-13670 [004] 425860.264977: kvm_mmu_pte_write: sp->gfn 18996 (offset=ef0) gfn 15253 invlpg=1 qemu-system-x86-13670 [004] 425860.265039: kvm_mmu_pte_write: sp->gfn 18996 (offset=ef0) gfn 15f15 invlpg=1 qemu-system-x86-13670 [004] 425860.266591: kvm_mmu_pte_write: sp->gfn 18996 (offset=ef0) gfn 146f3 invlpg=1 qemu-system-x86-13670 [004] 425860.268128: kvm_mmu_pte_write: sp->gfn 18996 (offset=ee8) gfn 14688 invlpg=1 qemu-system-x86-13670 [004] 425860.268592: kvm_mmu_pte_write: sp->gfn 18996 (offset=ef0) gfn 159c7 invlpg=1 qemu-system-x86-13669 [003] 425861.267453: kvm_mmu_zap_page: sp gfn 18996 1/4 q0 w-x pge nxe root 0 unsync The page is not shadowed again after this. gfn 0x159c7 above contains a valid "end of pool block" header: 00000000 00 00 00 00 00 00 00 00 10 10 00 00 00 00 00 00 |................| 00000010 00 01 01 03 46 72 61 67 1c 00 33 d2 48 8d 44 24 |....Frag..3.H.D$| 00000020 01 01 fe 00 46 72 65 65 48 8d 44 04 30 48 f7 f1 |....FreeH.D.0H..| But not the one which is in the pagetable at the time of BSOD: (qemu) xp /20x 0x1528a000 000000001528a000: 0x00000000 0x00000000 0x00000000 0x00000000 000000001528a010: 0x00000000 0x00000000 0x00000000 0x00000000 000000001528a020: 0x00000000 0x00000000 0x00000000 0x00000000 000000001528a030: 0x00000000 0x00000000 0x00000000 0x00000000 000000001528a040: 0x00000000 0x00000000 0x00000000 0x00000000 So my theory was, Windows wrote gfn 0x1528a to offset 0xef0, but skipped the invlpg, so a write to address 0xFFFFF8A000DDE000 ended up in the wrong gfn (the one prefaulted by the invlpg handler).
An alternative is that something fishy happpened to the pte mapping the page table. But that's far fetched.
So I'll commit the patch. I'm sorry to lose that optimization, I'll try later to track down what happened by reinstating the prefault but with the page marked not present, so we can see if a later fault fails to match the prefetch.
-- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
