On Wed, 28 Mar 2012 11:37:38 +0200
Avi Kivity <a...@redhat.com> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
