Re: Question about removing memslots

[Takuya Yoshikawa <yoshikawa.takuya@xxxxxxxxxxxxx>]

On Wed, 28 Mar 2012 11:37:38 +0200
Avi Kivity <avi@xxxxxxxxxx> wrote:

> > Now I see that x86 just seems to flush everything, which is quite heavy
> > handed considering how often cirrus does it, but maybe it doesn't have a
> > choice (lack of reverse mapping from GPA ?).
> 
> We do have a reverse mapping, so we could easily flush just a single
> slot.  The reason it hasn't been done is that slot changes are very are
> on x86.  They're usually only done by 16-bit software; 32-bit software
> just maps the entire framebuffer BAR and accesses it directly.  It's
> also usually done in a tight loop, so flushing everything doesn't have a
> large impact (and with a 20-bit address space, you couldn't cause a
> large impact if you wanted to - memory is all of 256 pages).

Even without using reverse mapping we can restrict that flush easily:

	http://www.spinics.net/lists/kvm/msg68695.html
	[PATCH] KVM: Avoid zapping unrelated shadows in __kvm_set_memory_region()

This would be better than using reverse mapping because we do not have so
many shadow pages when we are in a tight loop like you mensioned.

Anyway we could easily see tens of milliseconds difference by eliminating
unrelated flush.

	Takuya
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html