From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 06/16] vmx: nest: handling VMX instruction exits Date: Wed, 15 Sep 2010 09:23:11 +0100 Message-ID: References: <201009151015.20193.Christoph.Egger@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <201009151015.20193.Christoph.Egger@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christoph Egger , "xen-devel@lists.xensource.com" Cc: Tim Deegan , "Dong, Eddie" , "He, Qing" List-Id: xen-devel@lists.xenproject.org On 15/09/2010 09:15, "Christoph Egger" wrote: >> The main trick with x86_emulate extensions is determining the correct neat >> small set of callback hooks to add, which is somewhat driven by deciding >> what should be emulated within x86_emulate and what should be left without >> for implementation in the caller's context. > > There is a case where the host must emulate an instruction of the l2 guest > when the l1 guest doesn't intercept it. > > When the vcpu is in guest mode, the fields in struct hvm_vcpu and > guest_cpu_user_regs() represent the l2 guest state in my patch series. > > That way the instruction emulator works out-of-the box. Well in this specific case, all VMX-related instructions executed by an L2 guest would properly cause vmexit to the L1 guest for emulation there. We wouldn't want to emulate in Xen. But yes I can see that emulation of L2 guest instructions is needed in some other cases. Like instructions performing I/O in areas which L1 thinks it has given L2 direct unmediated access to, but which Xen is actually filtering or emulating. -- Keir > You need to add instructions to the emulator that are missing there.