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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
