Re: [PATCH 1/2] KVM: MMU: Mark sp mmio cached when creating mmio spte

[Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>]

On 03/13/2013 03:28 PM, Takuya Yoshikawa wrote:
> On Wed, 13 Mar 2013 13:06:23 +0800
> Xiao Guangrong <xiaoguangrong@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
> 
> 
>