All of lore.kernel.org
 help / color / mirror / Atom feed
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 <kvm@vger.kernel.org>
Subject: Re: [PATCH v2 02/12] KVM: x86: tag the instructions which are used to write page table
Date: Wed, 03 Aug 2011 17:24:28 +0800	[thread overview]
Message-ID: <4E3913CC.7010907@cn.fujitsu.com> (raw)
In-Reply-To: <4E39021F.8070508@redhat.com>

Hi Avi,

On 08/03/2011 04:09 PM, Avi Kivity wrote:
> On 08/03/2011 09:02 AM, Xiao Guangrong wrote:
>> >  Note we don't need to actually emulate, just decode, since page_fault can tell us whether a write failed due to page tables or mmio.
>> >
>>
>> This is a interesting feature. If it happens, i will just drop the shadow pages
>> and retry these instructions directly.
> 
> Note it's a little dangerous.  If the guest uses a non-page-table modifying instruction on the PDE that points to the instruction, then we will unmap the instruction and go to an infinite loop.
> 

Yes, it is.

> Maybe it's better to emulate if we can't find a fix for that.
> 
> One way would be to emulate every 20 instructions; this breaks us out of the loop but reduces costly emulations to 5%.
> 

After much thought about this, may be this optimization is not good since:
- it is little complex
- this optimization is only applied to the instruction emulation caused by #PF
- it does not improve too much:
  if we emulate the instruction, we need to do:
  - decode instruction
  - emulate it
  - zap shadow pages
  And do this, it can return to the guest, the guest can run the next instruction

  if we retry the instruction, we need to do:
  - decode instruction
  - zap shadow pages
  then return to the guest and retry the instruction, however, we will get page fault
  again(since the mapping is still read-only), so we will get another VM-exit and need
  to do:
  # trigger page fault
  - handle the page fault and change the mapping to writable
  - retry the instruction
  until now, the guest can run the next instruction

So, i do not think the new way is better, your opinion?


  
  

  reply	other threads:[~2011-08-03  9:22 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-02 11:06 [PATCH v2 01/12] KVM: MMU: avoid pte_list_desc run out in kvm_mmu_pte_write Xiao Guangrong
2011-08-02 11:07 ` [PATCH v2 02/12] KVM: x86: tag the instructions which are used to write page table Xiao Guangrong
2011-08-02 12:20   ` Avi Kivity
2011-08-03  6:02     ` Xiao Guangrong
2011-08-03  8:09       ` Avi Kivity
2011-08-03  9:24         ` Xiao Guangrong [this message]
2011-08-03  9:25           ` Avi Kivity
2011-08-03  9:41             ` Xiao Guangrong
2011-08-03  9:40               ` Avi Kivity
2011-08-02 11:08 ` [PATCH v2 03/12] zap sp if it is written by unaware instructions Xiao Guangrong
2011-08-02 11:08 ` [PATCH v2 04/12] KVM: x86: cleanup port-in/port-out emulated Xiao Guangrong
2011-08-02 11:09 ` [PATCH v2 05/12] KVM: x86: fast emulate repeat string write instructions Xiao Guangrong
2011-08-03  8:10   ` Avi Kivity
2011-08-03  9:31     ` Xiao Guangrong
2011-08-02 11:09 ` [PATCH v2 06/12] KVM: MMU: do not mark access bit on pte write path Xiao Guangrong
2011-08-02 11:10 ` [PATCH v2 07/12] KVM: MMU: cleanup FNAME(invlpg) Xiao Guangrong
2011-08-02 11:10 ` [PATCH v2 08/12] KVM: MMU: fast prefetch spte on invlpg path Xiao Guangrong
2011-08-02 18:36   ` Marcelo Tosatti
2011-08-03  6:03     ` Xiao Guangrong
2011-08-02 11:11 ` [PATCH v2 09/12] KVM: MMU: remove unnecessary kvm_mmu_free_some_pages Xiao Guangrong
2011-08-02 11:11 ` [PATCH v2 10/12] KVM: MMU: split kvm_mmu_pte_write function Xiao Guangrong
2011-08-02 11:12 ` [PATCH v2 11/12] KVM: MMU: fix detecting misaligned accessed Xiao Guangrong
2011-08-02 11:13 ` [PATCH v2 12/12] KVM: MMU: improve write flooding detected 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=4E3913CC.7010907@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.