All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Cc: mtosatti@redhat.com, kvm@vger.kernel.org, yoshikawa.takuya@oss.ntt.co.jp
Subject: Re: [PATCH] KVM: MMU: Use ptep_user for cmpxchg_gpte()
Date: Sat, 30 Apr 2011 22:48:39 +0300	[thread overview]
Message-ID: <4DBC6797.3080002@redhat.com> (raw)
In-Reply-To: <20110430235052.b8289513.takuya.yoshikawa@gmail.com>

On 04/30/2011 05:50 PM, Takuya Yoshikawa wrote:
> From: Takuya Yoshikawa<yoshikawa.takuya@oss.ntt.co.jp>
>
> The address of the gpte was already calculated and stored in ptep_user
> before entering cmpxchg_gpte().
>
> This patch makes cmpxchg_gpte() to use that to make it clear that we
> are using the same address during walk_addr_generic().
>
> Signed-off-by: Takuya Yoshikawa<yoshikawa.takuya@oss.ntt.co.jp>
> ---
>   Note: I tested this but could not see cmpxchg_gpte() being called.
>     Is there any good test case?

Run with npt or ept disabled.  With a normal OS you'll see A and D bits 
being set when the guest is under memory pressure, or when the guest 
uses a shared writeable mapping.  You can also try kvm-unit-tests.git's 
x86/access.flat test (also with npt/ept disabled).

>   static int FNAME(cmpxchg_gpte)(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu,
> -			 gfn_t table_gfn, unsigned index,
> -			 pt_element_t orig_pte, pt_element_t new_pte)
> +			       pt_element_t __user *ptep_user, unsigned index,
> +			       pt_element_t orig_pte, pt_element_t new_pte)
>   {
> +	int npages;
>   	pt_element_t ret;
>   	pt_element_t *table;
>   	struct page *page;
> -	gpa_t gpa;
>
> -	gpa = mmu->translate_gpa(vcpu, table_gfn<<  PAGE_SHIFT,
> -				 PFERR_USER_MASK|PFERR_WRITE_MASK);
> -	if (gpa == UNMAPPED_GVA)
> -		return -EFAULT;
> -
> -	page = gfn_to_page(vcpu->kvm, gpa_to_gfn(gpa));
> +	npages = get_user_pages_fast((unsigned long)ptep_user, 1, 1,&page);
> +	BUG_ON(npages != 1);

This BUG_ON() is user triggerable - have one thread munmap() guest 
memory while another thread runs guest code which triggers this path.  
You need to return an error here.  Or maybe you can just return - the 
user is doing something meaningless and there's no correct action here.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.


      reply	other threads:[~2011-04-30 19:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-30 14:50 [PATCH] KVM: MMU: Use ptep_user for cmpxchg_gpte() Takuya Yoshikawa
2011-04-30 19:48 ` Avi Kivity [this message]

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=4DBC6797.3080002@redhat.com \
    --to=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=takuya.yoshikawa@gmail.com \
    --cc=yoshikawa.takuya@oss.ntt.co.jp \
    /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.