From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [RFC] need to improve slot creation/destruction? -- Re:
 [RFC][PATCH] srcu: Implement call_srcu()
Date: Wed, 8 Feb 2012 16:45:31 -0200
Message-ID: <20120208184531.GA19883@amt.cnet>
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>
 <20120209004320.5772daa0472aef4700dab1b6@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: avi@redhat.com, kvm@vger.kernel.org
To: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:11228 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1757188Ab2BHSra (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 8 Feb 2012 13:47:30 -0500
Content-Disposition: inline
In-Reply-To: <20120209004320.5772daa0472aef4700dab1b6@gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Thu, Feb 09, 2012 at 12:43:20AM +0900, Takuya Yoshikawa wrote:
> [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 ...)

Yes, you can. The flush is there because a new slot invalidates any mmio
sptes in that region, but in the region covered by the new slot only.

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

If you enable dirty logging on a slot, certainly you have to write
protect?

> BTW do we really need fast slot creation/destruction?

At the moment yes. Boot a RHEL/Fedora installation disk (or any other
guest which uses SYSLINUX splash screen) and you will see. That
particular case is a limitation of cirrus in QEMU, ideally it should be
optimized there.