public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Xiao Guangrong <xiaoguangrong.eric@gmail.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>, KVM <kvm@vger.kernel.org>
Subject: Re: [PATCH] KVM: x86: fix missed memory synchronization when patch hypercall
Date: Sun, 09 Jun 2013 16:56:42 +0800	[thread overview]
Message-ID: <51B4434A.2010402@gmail.com> (raw)
In-Reply-To: <20130609084526.GH4725@redhat.com>

On 06/09/2013 04:45 PM, Gleb Natapov wrote:
> On Sat, Jun 08, 2013 at 11:15:37AM +0800, Xiao Guangrong wrote:
>> From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
>>
>> Currently, memory synchronization is missed in emulator_fix_hypercall,
>> please see the commit 758ccc89b83
>> (KVM: x86: drop calling kvm_mmu_zap_all in emulator_fix_hypercall)
>>
>> This patch fixes it by introducing kvm_vcpus_hang_on_page_start() and
>> kvm_vcpus_hang_on_page_end which unmap the patched page from guest
>> and use kvm_flush_remote_tlbs() as the serializing instruction to
>> ensure the memory coherence
>> [ The SDM said that INVEPT, INVVPID and MOV (to control register, with
>>   the exception of MOV CR8) are the serializing instructions. ]
>>
>> The mmu-lock is held during host patches the page so that it stops vcpus
>> to fix its further page fault
>>
> I have a patch to implement is much simple and in generic way, not
> relying on MMU internals.

I have considered this way but it seems not simple - it needs a new type of
request and it forces all vcpus to hang when host is patching the page.

My approach is just reusing the mmu code and requires vcpus to hang only when
the patched page is bing accessed.


  reply	other threads:[~2013-06-09  8:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-08  3:15 [PATCH] KVM: x86: fix missed memory synchronization when patch hypercall Xiao Guangrong
2013-06-09  8:45 ` Gleb Natapov
2013-06-09  8:56   ` Xiao Guangrong [this message]
2013-06-09  8:59     ` Gleb Natapov
2013-06-09  9:08       ` Xiao Guangrong
2013-06-09  9:29   ` Xiao Guangrong
2013-06-09  9:39     ` Gleb Natapov
2013-06-09 10:01       ` Xiao Guangrong
2013-06-09 10:19         ` Gleb Natapov
2013-06-09 11:25           ` Xiao Guangrong
2013-06-09 11:36             ` Gleb Natapov
2013-06-09 11:44               ` Xiao Guangrong
2013-06-09 11:56                 ` Gleb Natapov
2013-06-09 12:17                   ` Xiao Guangrong
2013-06-09 12:27                     ` Gleb Natapov
2013-06-09 12:52                       ` Xiao Guangrong
2013-06-18 14:13                       ` Paolo Bonzini
2013-06-18 15:22                         ` Gleb Natapov

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=51B4434A.2010402@gmail.com \
    --to=xiaoguangrong.eric@gmail.com \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@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