public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>, Avi Kivity <avi@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>, KVM <kvm@vger.kernel.org>
Subject: Re: [PATCH 3/3] KVM: x86: improve reexecute_instruction
Date: Mon, 03 Dec 2012 16:33:01 +0800	[thread overview]
Message-ID: <50BC63BD.70408@linux.vnet.ibm.com> (raw)
In-Reply-To: <20121129002132.GC17264@amt.cnet>

Hi Marcelo,

Thanks for your patience. I was reading your reply over and over again, i would
like to argue it more :).
Please see below.

On 11/29/2012 08:21 AM, Marcelo Tosatti wrote:

> 
> https://lkml.org/lkml/2012/11/17/75
> 
> Does unshadowing work with large sptes at reexecute_instruction? That
> is, do we nuke any large read-only sptes that might be causing a certain
> gfn to be read-only?
> 
> That is, following the sequence there, is the large read-only spte
> properly destroyed?

Actually, sptes can not prevent gfn becoming writable, that means the gfn
can become writable *even if* it exists a spte which maps to the gfn.

The condition that can prevent gfn becoming writable is, the gfn has been
shadowed, that means the gfn can not become writable if it exists a sp
with sp.gfn = gfn.

Note, drop_spte does not remove any sp. So, either destroying spte or keeping
spte doest not have any affect for gfn write-protection.

If luck enough, my point is right, the current code can do some optimizations
as below:

                if (level > PT_PAGE_TABLE_LEVEL &&
-                   has_wrprotected_page(vcpu->kvm, gfn, level)) {
-                       ret = 1;
-                       drop_spte(vcpu->kvm, sptep);
-                       goto done;
-               }
+                   has_wrprotected_page(vcpu->kvm, gfn, level))
+                       return 0;


1): we can return 0 instead of 1 to avoid unnecessary emulation. vcpu will refault
    again then kvm will use small page.

2): need not do any change on the spte.


  reply	other threads:[~2012-12-03  8:33 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-19 23:57 [PATCH 0/3] KVM: x86: improve reexecute_instruction Xiao Guangrong
2012-11-19 23:58 ` [PATCH 1/3] KVM: x86: clean up reexecute_instruction Xiao Guangrong
2012-11-20 12:11   ` Gleb Natapov
2012-11-20 20:13     ` Xiao Guangrong
2012-11-19 23:59 ` [PATCH 2/3] KVM: x86: let reexecute_instruction work for tdp Xiao Guangrong
2012-11-26 22:37   ` Marcelo Tosatti
2012-11-27  3:13     ` Xiao Guangrong
2012-11-27 23:32       ` Marcelo Tosatti
2012-11-28  3:15         ` Xiao Guangrong
2012-11-28 14:01           ` Gleb Natapov
2012-11-28 14:55             ` Xiao Guangrong
2012-11-28 22:07               ` Marcelo Tosatti
2012-11-19 23:59 ` [PATCH 3/3] KVM: x86: improve reexecute_instruction Xiao Guangrong
2012-11-26 22:41   ` Marcelo Tosatti
2012-11-27  3:30     ` Xiao Guangrong
2012-11-27 23:42       ` Marcelo Tosatti
2012-11-28  3:33         ` Xiao Guangrong
2012-11-28 14:12       ` Gleb Natapov
2012-11-28 14:59         ` Xiao Guangrong
2012-11-28 21:57           ` Marcelo Tosatti
2012-11-28 22:40             ` Xiao Guangrong
2012-11-28 23:16               ` Xiao Guangrong
2012-11-29  0:23                 ` Marcelo Tosatti
2012-11-29  0:21               ` Marcelo Tosatti
2012-12-03  8:33                 ` Xiao Guangrong [this message]
2012-12-03 19:47                   ` Marcelo Tosatti
2012-11-23  1:16 ` [PATCH 0/3] " Marcelo Tosatti

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=50BC63BD.70408@linux.vnet.ibm.com \
    --to=xiaoguangrong@linux.vnet.ibm.com \
    --cc=avi@redhat.com \
    --cc=gleb@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox