From: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
To: Avi Kivity <avi@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
KVM list <kvm@vger.kernel.org>
Subject: Re: [PATCH v2 3/10] KVM: MMU: fix direct sp's access corruptted
Date: Tue, 29 Jun 2010 17:04:00 +0800 [thread overview]
Message-ID: <4C29B700.8040502@cn.fujitsu.com> (raw)
In-Reply-To: <4C29B390.80602@redhat.com>
Avi Kivity wrote:
> On 06/29/2010 10:35 AM, Xiao Guangrong wrote:
>>
>>> We have now
>>>
>>> if (is_shadow_present_pte(*sptep)&& !is_large_pte(*sptep))
>>> continue;
>>>
>>> So we need to add a check, if sp->role.access doesn't match pt_access&
>>> pte_access, we need to get a new sp with the correct access (can only
>>> change read->write).
>>>
>>>
>> Umm, we should update the spte at the gw->level, so we need get the child
>> sp, and compare its access at this point, just like this:
>>
>> if (level == gw->level&& is_shadow_present_pte(*sptep)) {
>> child_sp = page_header(__pa(*sptep& PT64_BASE_ADDR_MASK));
>>
>> if (child_sp->access != pt_access& pte_access& (diry ? 1 :
>> ~ACC_WRITE_MASK )) {
>> /* Zap sptep */
>> ......
>> }
>>
>> }
>>
>> So, why not use the new spte flag (SPTE_NO_DIRTY in my patch) to mark
>> this spte then we can see
>> this spte whether need updated directly? i think it more simpler ;-)
>>
>
> It's new state, and new state means more maintenance of that state and
> the need to consider the state in all relevant code paths.
>
> In terms of maintainability, changing walk_addr() is best, since it
> maintains the tight invariant that PT_PAGE_DIRECTORY_LEVEL sptes are
> always consistent with their sptes. Updating fetch() to allow for a
> relaxed invariant (spte may be read-only while gpte is write-dirty) is
> more complicated, but performs better. This is also consistent with
> what we do with PT_PAGE_TABLE_LEVEL gptes/sptes and with unsync pages.
>
Maybe you are right, i just think is more quickly by using SPTE_NO_DIRTY flag
to judge whether need updated. I'll modify this patch as your suggestion.
> btw, how can the patch work?
>
>>
>> + if (level == gw->level&& !dirty&&
>> + access& gw->pte_access& ACC_WRITE_MASK)
>> + spte |= SPTE_NO_DIRTY;
>> +
>> spte = __pa(sp->spt)
>> | PT_PRESENT_MASK | PT_ACCESSED_MASK
>> | PT_WRITABLE_MASK | PT_USER_MASK;
>>
>
> spte is immediately overwritten by the following assignment.
>
Ah, sorry, i miss it, spte |= SPTE_NO_DIRTY should behind of following assignment.
> However, the other half of the patch can be adapted:
>
>>
>> + if (*sptep& SPTE_NO_DIRTY) {
>> + struct kvm_mmu_page *child;
>> +
>> + WARN_ON(level != gw->level);
>> + WARN_ON(!is_shadow_present_pte(*sptep));
>> + if (dirty) {
>> + child = page_header(*sptep&
>> + PT64_BASE_ADDR_MASK);
>> + mmu_page_remove_parent_pte(child, sptep);
>> + __set_spte(sptep, shadow_trap_nonpresent_pte);
>> + kvm_flush_remote_tlbs(vcpu->kvm);
>> + }
>> + }
>> +
>> if (is_shadow_present_pte(*sptep)&& !is_large_pte(*sptep))
>> continue;
>>
>
> Simply replace (*spte & SPTE_NO_DIRTY) with a condition that checks
> whether sp->access is consistent with gw->pt(e)_access.
>
If the guest mapping is writable and it !dirty, we mark SPTE_NO_DIRTY flag in
the spte, when the next #PF occurs, we just need check this flag and see whether
gpte's D bit is set, if it's true, we zap this spte and map to the correct sp.
> Can you write a test case for qemu-kvm.git/kvm/test that demonstrates
> the problem and the fix? It will help ensure we don't regress in this
> area.
>
OK, but allow me do it later :-)
next prev parent reply other threads:[~2010-06-29 9:07 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4C2498EC.2010006@cn.fujitsu.com>
2010-06-25 12:05 ` [PATCH v2 2/10] KVM: MMU: fix conflict access permissions in direct sp Xiao Guangrong
2010-06-28 9:43 ` Avi Kivity
2010-06-28 9:49 ` Xiao Guangrong
2010-06-25 12:06 ` [PATCH v2 3/10] KVM: MMU: fix direct sp's access corruptted Xiao Guangrong
2010-06-28 9:50 ` Avi Kivity
2010-06-28 10:02 ` Xiao Guangrong
2010-06-28 11:13 ` Avi Kivity
2010-06-29 1:17 ` Xiao Guangrong
2010-06-29 7:06 ` Avi Kivity
2010-06-29 7:35 ` Xiao Guangrong
2010-06-29 8:49 ` Avi Kivity
2010-06-29 9:04 ` Xiao Guangrong [this message]
2010-06-29 9:13 ` Avi Kivity
2010-06-29 9:13 ` Xiao Guangrong
2010-06-29 7:38 ` Avi Kivity
2010-06-29 7:45 ` Xiao Guangrong
2010-06-29 8:51 ` Avi Kivity
2010-06-29 9:08 ` Xiao Guangrong
2010-06-25 12:06 ` [PATCH v2 4/10] KVM: MMU: fix forgot to flush all vcpu's tlb Xiao Guangrong
2010-06-28 9:55 ` Avi Kivity
2010-06-25 12:06 ` [PATCH v2 5/10] KVM: MMU: introduce gfn_to_pfn_atomic() function Xiao Guangrong
2010-06-25 12:06 ` [PATCH v2 6/10] KVM: MMU: introduce gfn_to_hva_many() function Xiao Guangrong
2010-06-25 12:06 ` [PATCH v2 7/10] KVM: MMU: introduce mmu_topup_memory_cache_atomic() Xiao Guangrong
2010-06-28 11:17 ` Avi Kivity
2010-06-29 1:18 ` Xiao Guangrong
2010-06-25 12:07 ` [PATCH v2 8/10] KVM: MMU: prefetch ptes when intercepted guest #PF Xiao Guangrong
2010-06-28 13:04 ` Marcelo Tosatti
2010-06-29 8:07 ` Xiao Guangrong
2010-06-29 11:44 ` Marcelo Tosatti
2010-06-30 0:58 ` Xiao Guangrong
2010-06-25 12:07 ` [PATCH v2 9/10] KVM: MMU: combine guest pte read between walk and pte prefetch Xiao Guangrong
2010-06-25 12:07 ` [PATCH v2 10/10] KVM: MMU: trace " Xiao Guangrong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C29B700.8040502@cn.fujitsu.com \
--to=xiaoguangrong@cn.fujitsu.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.