From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Tosatti <mtosatti-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: Any comments? Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic:
 moving dirty bitmaps to user space
Date: Tue, 1 Jun 2010 07:55:49 -0300
Message-ID: <20100601105549.GA1975@amt.cnet>
References: <20100504215645.6448af8f.takuya.yoshikawa@gmail.com>
 <4BE7F6D7.3060005@redhat.com>
 <4BE7FB7B.5010600@oss.ntt.co.jp>
 <4BEBE6D0.8020000@redhat.com>
 <4BF1070B.4000507@oss.ntt.co.jp>
 <4BFA2539.3030709@oss.ntt.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Avi Kivity <avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Takuya Yoshikawa <takuya.yoshikawa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, agraf-l3A5Bk7waGM@public.gmane.org,
	fernando-gVGce1chcLdL9jVzuh4AOg@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kvm-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
To: Takuya Yoshikawa <yoshikawa.takuya-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
Return-path: <kvm-ppc-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Content-Disposition: inline
In-Reply-To: <4BFA2539.3030709-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
Sender: kvm-ppc-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
List-Id: kvm.vger.kernel.org

On Mon, May 24, 2010 at 04:05:29PM +0900, Takuya Yoshikawa wrote:
> (2010/05/17 18:06), Takuya Yoshikawa wrote:
> >
> >>User allocated bitmaps have the advantage of reducing pinned memory.
> >>However we have plenty more pinned memory allocated in memory slots, so
> >>by itself, user allocated bitmaps don't justify this change.
> 
> Sorry for pinging several times.
> 
> >
> >In that sense, what do you think about the question I sent last week?
> >
> >=== REPOST 1 ===
> > >>
> > >> mark_page_dirty is called with the mmu_lock spinlock held in set_spte.
> > >> Must find a way to move it outside of the spinlock section.
> 
> I am now trying to do something to solve this spinlock problem. But the
> spinlock section looks too wide to solve with simple workaround.
> 
> >Sorry but I have to say that mmu_lock spin_lock problem was completely
> >out of
> >my mind. Although I looked through the code, it seems not easy to move the
> >set_bit_user to outside of spinlock section without breaking the
> >semantics of
> >its protection.
> >
> >So this may take some time to solve.
> >
> >But personally, I want to do something for x86's "vmallc() every time"
> >problem
> >even though moving dirty bitmaps to user space cannot be achieved soon.
> >
> >In that sense, do you mind if we do double buffering without moving
> >dirty bitmaps to
> >user space?
> 
> So I would be happy if you give me any comments about this kind of other
> options.

What if you pin the bitmaps? 

The alternative to that is to move mark_page_dirty(gfn) before acquision 
of mmu_lock, in the page fault paths. The downside of that is a
potentially (large?) number of false positives in the dirty bitmap.