On 03/30/2012 05:18 PM, Xiao Guangrong wrote:
> On 03/29/2012 08:57 PM, Avi Kivity wrote:
>
>> On 03/29/2012 01:40 PM, Xiao Guangrong wrote:
>>>>> * Implementation
>>>>> We can freely walk the page between walk_shadow_page_lockless_begin and
>>>>> walk_shadow_page_lockless_end, it can ensure all the shadow page is valid.
>>>>>
>>>>> In the most case, cmpxchg is fair enough to change the access bit of spte,
>>>>> but the write-protect path on softmmu/nested mmu is a especial case: it is
>>>>> a read-check-modify path: read spte, check W bit, then clear W bit.
>>>>
>>>> We also set gpte.D and gpte.A, no? How do you handle that?
>>>>
>>>
>>>
>>> We still need walk gust page table before fast page fault to check
>>> whether the access is valid.
>>
>> Ok. But that's outside the mmu lock.
>>
>> We can also skip that: if !sp->unsync, copy access rights and gpte.A/D
>> into spare bits in the spte, and use that to check.
>>
>
>
> Great!
>
> gpte.A need not be copied into spte since EFEC.P = 1 means the shadow page
> table is present, gpte.A must be set in this case.
>
> And, we do not need to cache gpte access rights into spte, instead of it,
> we can atomicly read gpte to get these information (anyway, we need read gpte
> to get the gfn.)
>
It needs more thinking, we can excellent improvement for dirty page logged in
this idea, but i am not sure we can gain the performance in the below case:
- the page fault is trigged by the invalid access from guest
in the origin way, it is fixed on the FNAME(walk_addr) path which walk guest page
table, we way need call gfn_to_pfn (it is fast since the page is always not
swap out). After the idea, it is fixed on fast page fault path which walk shadow
page table with RCU locked, the preemption is disabled.
They are not too different i think.
- the page fault is caused by host, but we can not quickly check the page writable
since gfn is unknown, then after shadow page walking we get the gfn (read gpte),
what will we do if gfn is write-protect?
- if the page is write-protected by the host (!spte.SPTE_HOST_WRITEABLE), we have
no choice, just call gfn_to_pfn and waiting the page cowed.
Comparing with the origin way, the time costed on shadow page table walking is
wasted, unfortunately, it is triggered really frequently if KSM is enabled. It
may be a regression.
- if the write-protect is caused by page table protected, we have two choice:
- call slow page fault path. It is unacceptable, since the number of this kind
of page fault is very large. We may wast many CPU time.
- hold mmu-lock and fix it in the last spte. It is OK but makes thing little
complex, i am not sure if you agree with this. :)
--
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
