linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Xiao Guangrong <xiaoguangrong@cn.fujitsu.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 11:49:20 +0300	[thread overview]
Message-ID: <4C29B390.80602@redhat.com> (raw)
In-Reply-To: <4C29A25C.7040900@cn.fujitsu.com>

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.

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.

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.

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.

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2010-06-29  8:49 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 [this message]
2010-06-29  9:04                 ` Xiao Guangrong
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=4C29B390.80602@redhat.com \
    --to=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=xiaoguangrong@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).