From: Avi Kivity <avi@redhat.com>
To: mtosatti@redhat.com
Cc: kvm@vger.kernel.org
Subject: Re: [patch 3/4] KVM: introduce kvm_arch_can_free_memslot, disallow slot deletion if cached cr3
Date: Sun, 10 May 2009 19:40:16 +0300 [thread overview]
Message-ID: <4A070370.5000501@redhat.com> (raw)
In-Reply-To: <20090507210534.058747069@amt.cnet>
mtosatti@redhat.com wrote:
> Disallow the deletion of memory slots (and aliases, for x86 case), if a
> vcpu contains a cr3 that points to such slot/alias.
>
> This complements commit 6c20e1442bb1c62914bb85b7f4a38973d2a423ba.
>
> v2:
> - set KVM_REQ_TRIPLE_FAULT
> - use __KVM_HAVE_ARCH_CAN_FREE_MEMSLOT to avoid duplication of stub
>
> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>
> Index: kvm-pending/arch/x86/kvm/x86.c
> ===================================================================
> --- kvm-pending.orig/arch/x86/kvm/x86.c
> +++ kvm-pending/arch/x86/kvm/x86.c
> @@ -1636,6 +1636,29 @@ gfn_t unalias_gfn(struct kvm *kvm, gfn_t
> return gfn;
> }
>
> +static int kvm_root_gfn_in_range(struct kvm *kvm, gfn_t base_gfn,
> + gfn_t end_gfn, bool unalias)
> +{
> + struct kvm_vcpu *vcpu;
> + gfn_t root_gfn;
> + int i;
> +
> + for (i = 0; i < KVM_MAX_VCPUS; ++i) {
> + vcpu = kvm->vcpus[i];
> + if (!vcpu)
> + continue;
> + root_gfn = vcpu->arch.cr3 >> PAGE_SHIFT;
>
The guest may have changed this by now.
> + if (unalias)
> + root_gfn = unalias_gfn(kvm, root_gfn);
> + if (root_gfn >= base_gfn && root_gfn <= end_gfn) {
> + set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests);
> + return 1;
> + }
> + }
> +
> + return 0;
> +}
> +
>
The naming is bad, a function named as a predicate shouldn't have side
effects.
Also, we should allow deleting the slot. There's no reason to deny
userspace something just because the guest is playing around
I think this should be enough:
- take mmu lock
- request an mmu reload from all vcpus
- drop the slot
- release mmu lock
The reload will inject a #GP if cr3 is now out of bounds, should be
changed to triple fault, but everything is in place (set_cr3 already
checks).
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2009-05-10 16:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-27 20:06 [patch 0/4] set_memory_region locking fixes / vcpu->arch.cr3 + removal of memslots mtosatti
2009-04-27 20:06 ` [patch 1/4] KVM: MMU: protect kvm_mmu_change_mmu_pages with mmu_lock mtosatti
2009-04-27 20:06 ` [patch 2/4] KVM: take mmu_lock when updating a deleted slot mtosatti
2009-04-27 20:06 ` [patch 3/4] KVM: introduce kvm_arch_can_free_memslot, disallow slot deletion if cached cr3 mtosatti
2009-05-07 14:16 ` Avi Kivity
2009-05-07 18:58 ` Marcelo Tosatti
2009-05-07 21:03 ` [patch 0/4] set_memory_region locking fixes / cr3 vs removal of memslots v2 mtosatti
2009-05-07 21:03 ` [patch 1/4] KVM: MMU: protect kvm_mmu_change_mmu_pages with mmu_lock mtosatti
2009-05-07 21:03 ` [patch 2/4] KVM: take mmu_lock when updating a deleted slot mtosatti
2009-05-07 21:03 ` [patch 3/4] KVM: introduce kvm_arch_can_free_memslot, disallow slot deletion if cached cr3 mtosatti
2009-05-10 16:40 ` Avi Kivity [this message]
2009-05-12 21:55 ` [patch 0/3] locking fixes / cr3 validation v3 mtosatti
2009-05-12 21:55 ` [patch 1/3] KVM: MMU: protect kvm_mmu_change_mmu_pages with mmu_lock mtosatti
2009-05-12 21:55 ` [patch 2/3] KVM: take mmu_lock when updating a deleted slot mtosatti
2009-05-12 21:55 ` [patch 3/3] KVM: x86: check for cr3 validity in mmu_alloc_roots mtosatti
2009-05-13 7:40 ` [patch 0/3] locking fixes / cr3 validation v3 Avi Kivity
2009-05-07 21:03 ` [patch 4/4] KVM: x86: disallow changing a slots size mtosatti
2009-04-27 20:06 ` mtosatti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A070370.5000501@redhat.com \
--to=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.