From mboxrd@z Thu Jan  1 00:00:00 1970
From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Subject: Re: [PATCH v3 10/13] nEPT: Nested INVEPT
Date: Tue, 21 May 2013 17:16:18 +0800
Message-ID: <519B3B62.8060904@linux.vnet.ibm.com>
References: <1368939152-11406-1-git-send-email-jun.nakajima@intel.com> <1368939152-11406-10-git-send-email-jun.nakajima@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: kvm@vger.kernel.org, Gleb Natapov <gleb@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
To: Jun Nakajima <jun.nakajima@intel.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from e28smtp04.in.ibm.com ([122.248.162.4]:50700 "EHLO
	e28smtp04.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750816Ab3EUJQb (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 21 May 2013 05:16:31 -0400
Received: from /spool/local
	by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted
	for <kvm@vger.kernel.org> from <xiaoguangrong@linux.vnet.ibm.com>;
	Tue, 21 May 2013 14:41:17 +0530
Received: from d28relay02.in.ibm.com (d28relay02.in.ibm.com [9.184.220.59])
	by d28dlp03.in.ibm.com (Postfix) with ESMTP id 1B97A1258052
	for <kvm@vger.kernel.org>; Tue, 21 May 2013 14:48:23 +0530 (IST)
Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r4L9GIii18808986
	for <kvm@vger.kernel.org>; Tue, 21 May 2013 14:46:19 +0530
Received: from d28av04.in.ibm.com (loopback [127.0.0.1])
	by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r4L9GNFW004195
	for <kvm@vger.kernel.org>; Tue, 21 May 2013 19:16:23 +1000
In-Reply-To: <1368939152-11406-10-git-send-email-jun.nakajima@intel.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 05/19/2013 12:52 PM, Jun Nakajima wrote:
> From: Nadav Har'El <nyh@il.ibm.com>
> 
> If we let L1 use EPT, we should probably also support the INVEPT instruction.
> 
> In our current nested EPT implementation, when L1 changes its EPT table for
> L2 (i.e., EPT12), L0 modifies the shadow EPT table (EPT02), and in the course

Hmm?

L0 can not always intercept L1's changes due to unsync shadow pages...

> of this modification already calls INVEPT. Therefore, when L1 calls INVEPT,
> we don't really need to do anything. In particular we *don't* need to call

So, i can not understand why we need not handle INVEPT.