Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752550AbdF3TGX (ORCPT ); Fri, 30 Jun 2017 15:06:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55354 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752444AbdF3TGW (ORCPT ); Fri, 30 Jun 2017 15:06:22 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5A0DF612B5 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=pbonzini@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5A0DF612B5 Date: Fri, 30 Jun 2017 15:06:18 -0400 (EDT) From: Paolo Bonzini To: Jim Mattson Cc: Bandan Das , kvm list , LKML Message-ID: <991849943.13167224.1498849578947.JavaMail.zimbra@redhat.com> In-Reply-To: References: <20170629232956.12300-1-bsd@redhat.com> Subject: Re: [PATCH 0/2] Expose VMFUNC to the nested hypervisor MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [94.39.191.51, 10.4.196.19, 10.4.195.8] Thread-Topic: Expose VMFUNC to the nested hypervisor Thread-Index: uELGLZ97ZFnxqP+zxxrapCN+ocKoRg== X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 30 Jun 2017 19:06:21 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1522 Lines: 45 ----- Original Message ----- > From: "Jim Mattson" > To: "Bandan Das" > Cc: "kvm list" , "Paolo Bonzini" , "LKML" > Sent: Friday, June 30, 2017 7:06:43 PM > Subject: Re: [PATCH 0/2] Expose VMFUNC to the nested hypervisor > > Isn't McAfee DeepSAFE defunct? Are there any other consumers of EPTP > switching? Xen can use it optionally, and #VE as well. Paolo > On Thu, Jun 29, 2017 at 4:29 PM, Bandan Das wrote: > > These patches expose eptp switching/vmfunc to the nested hypervisor. > > Testing with > > kvm-unit-tests seems to work ok. > > > > If the guest hypervisor enables vmfunc/eptp switching, a "shadow" eptp list > > address page is written to the VMCS. Initially, it would be unpopulated > > which > > would result in a vmexit with exit reason 59. This hooks to handle_vmfunc() > > to rewrite vmcs12->ept_pointer to reload the mmu and get a new root hpa. > > This new shadow ept pointer is written to the shadow eptp list in the given > > index. A next vmfunc call to switch to the given index would succeed > > without > > an exit. > > > > Bandan Das (2): > > KVM: nVMX: Implement EPTP switching for the L1 hypervisor > > KVM: nVMX: Advertise VMFUNC to L1 hypervisor > > > > arch/x86/include/asm/vmx.h | 9 ++++ > > arch/x86/kvm/vmx.c | 122 > > +++++++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 131 insertions(+) > > > > -- > > 2.9.4 > > >