From mboxrd@z Thu Jan  1 00:00:00 1970
From: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Subject: [RFC] need to improve slot creation/destruction? -- Re:
 [RFC][PATCH] srcu: Implement call_srcu()
Date: Thu, 9 Feb 2012 00:43:20 +0900
Message-ID: <20120209004320.5772daa0472aef4700dab1b6@gmail.com>
References: <1328016724.2446.229.camel@twins>
	<4F27F0E6.1040309@redhat.com>
	<1328017807.2446.230.camel@twins>
	<20120131222447.GH2391@linux.vnet.ibm.com>
	<1328091749.2760.34.camel@laptop>
	<4F29178A.1090306@redhat.com>
	<4F2918D5.4050104@redhat.com>
	<20120201135020.GB18998@amt.cnet>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: avi@redhat.com, kvm@vger.kernel.org
To: mtosatti@redhat.com
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-gy0-f174.google.com ([209.85.160.174]:63672 "EHLO
	mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1756537Ab2BHPnZ (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 8 Feb 2012 10:43:25 -0500
Received: by ghrr11 with SMTP id r11so277723ghr.19
        for <kvm@vger.kernel.org>; Wed, 08 Feb 2012 07:43:24 -0800 (PST)
In-Reply-To: <20120201135020.GB18998@amt.cnet>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

[Dropped non-kvm members from cc]

Marcelo Tosatti <mtosatti@redhat.com> wrote:

> VGABIOS mode constantly destroys and creates 0xa0000 slot, so
> performance is required for KVM_SET_MEM too (it can probably be fixed in
> qemu, but older qemu's must be supported).

Apart from srcu, I see some problems concerning slot creation/destruction:
heavy shadow flush (and extra write protection).


Look at __kvm_set_memory_region().

1. When we invalidate a memory slot, we call kvm_arch_flush_shadow() and
zap all shadow pages, not restricted to that slot.

	/* From this point no new shadow pages pointing to a deleted
	 * memslot will be created.
	 *
	 * validation of sp->gfn happens in:
	 *	- gfn_to_hva (kvm_read_guest, gfn_to_pfn)
	 *	- kvm_is_visible_gfn (mmu_check_roots)
	 */
	kvm_arch_flush_shadow(kvm);

2. When we create(and shift?) a memory slot, we call kvm_arch_flush_shadow()
to clear all mmio sptes, again not restricted to that slot.

	/*
	 * If the new memory slot is created, we need to clear all
	 * mmio sptes.
	 */
	if (npages && old.base_gfn != mem->guest_phys_addr >> PAGE_SHIFT)
		kvm_arch_flush_shadow(kvm);

3. In addition to these, we do write-protect all pages in that slot in
kvm_arch_commit_memory_region() every time.


For 1:  I made a patch to restrict the flush to that slot by using sp->slot_bitmap.
(seems working here)

For 2:  I think we can do the same:  not 100% sure yet because I am still
struggling with the "mmio spte optimization" code.  (really hacky ...)

For 3:  I think doing both "write protection" and "shadow flush" is unnecessary.


BTW do we really need fast slot creation/destruction?

	Takuya