On 03/29/2012 07:15 AM, Takuya Yoshikawa wrote: > 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. Hm, the patch uses ->slot_bitmap which we might want to kill if we increase the number of slots dramatically, as some people want to do. btw, what happened to that patch, did it just get ignored on the list? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
