Re: KVM: MMU: nuke shadowed pgtable pages and pte's on memslot destruction

Avi Kivity
2008-07-05T17:25:13Z

Marcelo Tosatti wrote:
> During RH6.2 graphical installation the following oops is triggered:
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> IP: [<ffffffffa00bf172>] :kvm:gfn_to_rmap+0x3e/0x61
> Pid: 4559, comm: qemu-system-x86 Not tainted
> RIP: 0010:[<ffffffffa00bf172>] [<ffffffffa00bf172>] :kvm:gfn_to_rmap+0x3e/0x61
>
> @@ -1955,6 +1955,22 @@ void kvm_mmu_slot_remove_write_access(st
> }
> }
>
> +int kvm_mmu_slot_has_shadowed_page(struct kvm *kvm, int slot)
> +{
> + struct kvm_mmu_page *sp;
> + int ret = 0;
> +
> + spin_lock(&kvm->mmu_lock);
> + list_for_each_entry(sp, &kvm->arch.active_mmu_pages, link) {
> + if (test_bit(slot, &sp->slot_bitmap)) {
> + ret = -EINVAL;
> + break;
> + }
> + }
> + spin_unlock(&kvm->mmu_lock);
> + return ret;
> +}
> +
>

I don't like the guest influencing host actions in this way. It's just
a guest.

But I think it's unneeded. kvm_mmu_zap_page() will mark a root shadow
page invalid and force all vcpus to reload it, so all that's needed is
to keep the mmu spinlock held while removing the slot.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.