From: Avi Kivity <avi@qumranet.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: "Richard W.M. Jones" <rjones@redhat.com>,
kvm-devel <kvm@vger.kernel.org>,
Hollis Blanchard <hollisb@us.ibm.com>,
"Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: Re: KVM: MMU: nuke shadowed pgtable pages and pte's on memslot destruction
Date: Thu, 10 Jul 2008 17:42:19 +0300 [thread overview]
Message-ID: <48761FCB.4080307@qumranet.com> (raw)
In-Reply-To: <20080707195822.GA16787@dmt.cnet>
Marcelo Tosatti wrote:
> On Mon, Jul 07, 2008 at 02:31:55PM -0300, Marcelo Tosatti wrote:
>
>> On Sun, Jul 06, 2008 at 12:15:56AM +0300, Avi Kivity wrote:
>>
>>> Marcelo Tosatti wrote:
>>>
>>>> On Sat, Jul 05, 2008 at 08:25:30PM +0300, Avi Kivity wrote:
>>>>
>>>>
>>>>>> @@ -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.
>>>>>
>>>>>
>>>> You're still keeping a shadowed page around with sp->gfn pointing to
>>>> non-existant memslot. The code generally makes the assumption that
>>>> gfn_to_memslot(gfn) on shadowed info will not fail.
>>>>
>>>> kvm_mmu_zap_page -> unaccount_shadowed, for example.
>>>>
>>>>
>>>>
>>> The page has already been zapped, so we might as well
>>> unaccount_shadowed() on the first run. It needs to be moved until after
>>> the reload_remote_mmus() call, though.
>>>
>
> Oops, previous patch was unaccounting multiple times for invalid pages.
> This should be better:
>
>
> 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
>
> The problem is that KVM allows shadow pagetable entries that
> point to a removed memslot to exist. In this case the cirrus vram
> mapping was removed, and the NULL dereference happened during
> kvm_set_memory_alias()'s zap_all_pages().
>
> So nuke all shadowed pages before memslot removal.
>
> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>
>
> diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
> index a4cf4a2..76259da 100644
> --- a/arch/ia64/kvm/kvm-ia64.c
> +++ b/arch/ia64/kvm/kvm-ia64.c
> @@ -1455,6 +1455,10 @@ int kvm_arch_set_memory_region(struct kvm *kvm,
> return 0;
> }
>
> +int kvm_arch_destroy_memory_region(struct kvm *kvm, int slot)
> +{
> + return 0;
> +}
>
>
This (and its friends) ought to be static inlines.
On the other hand, don't the other arches have to flush their tlbs?
Xiantao/Hollis? So maybe this function needs to be renamed
kvm_flush_shadow() and implemented across the board.
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index b90da0b..5ef3a5e 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -405,6 +405,12 @@ int __kvm_set_memory_region(struct kvm *kvm,
> if (mem->slot >= kvm->nmemslots)
> kvm->nmemslots = mem->slot + 1;
>
> + if (!npages) {
> + r = kvm_arch_destroy_memory_region(kvm, mem->slot);
> + if (r)
> + goto out_free;
> + }
> +
>
Destructors should never fail, since there is no possible recovery. And
indeed you have 'return 0' in the actual implementation. So I think the
function better return void.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2008-07-10 14:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-04 1:06 KVM: MMU: nuke shadowed pgtable pages and pte's on memslot destruction Marcelo Tosatti
2008-07-05 17:25 ` Avi Kivity
2008-07-05 19:23 ` Marcelo Tosatti
2008-07-05 21:15 ` Avi Kivity
2008-07-07 17:31 ` Marcelo Tosatti
2008-07-07 19:58 ` Marcelo Tosatti
2008-07-10 14:42 ` Avi Kivity [this message]
2008-07-10 18:58 ` Hollis Blanchard
2008-07-10 23:49 ` Marcelo Tosatti
2008-07-11 14:48 ` Avi Kivity
2008-07-21 21:03 ` Hollis Blanchard
2008-07-21 21:34 ` Marcelo Tosatti
2008-07-21 22:22 ` Hollis Blanchard
2008-07-22 5:18 ` Avi Kivity
2008-07-10 23:54 ` Marcelo Tosatti
2008-07-11 15:09 ` Avi Kivity
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=48761FCB.4080307@qumranet.com \
--to=avi@qumranet.com \
--cc=hollisb@us.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=rjones@redhat.com \
--cc=xiantao.zhang@intel.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.