On 03/13/2013 03:28 PM, Takuya Yoshikawa wrote: > On Wed, 13 Mar 2013 13:06:23 +0800 > Xiao Guangrong <xiaoguangr...@linux.vnet.ibm.com> wrote: > >> On 03/12/2013 04:44 PM, Takuya Yoshikawa wrote: >>> This will be used not to zap unrelated mmu pages when creating/moving >>> a memory slot later. >> >> How about save all mmio spte into a mmio-rmap? > > The problem is that other mmu code would need to care about the pointers > stored in the new rmap list: when mmu_shrink zaps shadow pages for example.
It is not hard... all the codes have been wrapped by *zap_spte*. > > Maybe worth thinking about, but I want to have a simple, back-portable patch > for distributors, as a first step: note that creating a memory slot can happen > many times for some guest configurations since QEMU is doing strange things > for re-mapping some regions IIRC. Hmm, that means also need to delete memslot frequently, this patch can not help much on deletion case. > >> >> The good things are: >> - instead walking all shadow page, we can only walk the rmap > > Traversing the active list does not take such a long time compared to > other things to do for zapping pages: us, not ms order. But I'm now Walking shadow page depends on how much memory used on guest... > preparing for an additional work to avoid "goto restart" after deleting > entries. That will at least help us not to traverse more than once. If drop the walking, so you need not care "goto" stuff anymore... > >> - Comparing to zap a shadow page, it does not need to flush TLB after >> zapping mmio sptes > > If we check each spte in the sp, we can achieve the similar goal: > similar to the old remove_write_access() code. I implemented such > code but have not seen a clear improvement yet. Pros and cons will > be there. Checking every entries (512) in the shadow page is bad... > > Thanks, > Takuya > > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
