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
