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

[Avi Kivity <avi@qumranet.com>]

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.