From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751764AbdJSHOg (ORCPT ); Thu, 19 Oct 2017 03:14:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37238 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751436AbdJSHOf (ORCPT ); Thu, 19 Oct 2017 03:14:35 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D9265C0587F7 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=pbonzini@redhat.com Subject: Re: [PATCH 0/9] Intel Processor Trace virtulization enabling To: "Kang, Luwei" , "kvm@vger.kernel.org" Cc: "rkrcmar@redhat.com" , "tglx@linutronix.de" , "mingo@redhat.com" , "hpa@zytor.com" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , Chao Peng References: <1508155781-4576-1-git-send-email-luwei.kang@intel.com> <66f40c86-cdf3-84a7-6d42-c0c7f6850e19@redhat.com> <82D7661F83C1A047AF7DC287873BF1E167E1B5FB@SHSMSX101.ccr.corp.intel.com> <0ca0d53b-640a-c124-08dc-dbf009e01a8e@redhat.com> <82D7661F83C1A047AF7DC287873BF1E167E1B74A@SHSMSX101.ccr.corp.intel.com> <5b434733-c974-9012-0e08-48ed9e1d2fa6@redhat.com> <82D7661F83C1A047AF7DC287873BF1E167E1C475@SHSMSX101.ccr.corp.intel.com> From: Paolo Bonzini Message-ID: Date: Thu, 19 Oct 2017 09:14:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <82D7661F83C1A047AF7DC287873BF1E167E1C475@SHSMSX101.ccr.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 19 Oct 2017 07:14:35 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19/10/2017 07:54, Kang, Luwei wrote: >>> Get it. I have feedback to hardware architect. I hope it can be applied but it may need wait a long time. >> Note that the hardware need not do anything. However it would be nice if the SDM can define a bit _for the hypervisors_ to >> enforce the above constraint and fail vmentry if they are not respected. > > Hi Paolo, > Thanks for your response. I have a question want to ask for you. As > you mentioned in previous mail " We would like the nested hypervisor > to be forced to set the "use GPA for processor tracing"". Is there > have any problem if we don't set "use GPA for processor tracing" in > nested hypervisor? If the nested hypervisor doesn't set "use GPA for processor tracing", the processor should use L1 addresses for processor tracing. This however is not possible without shadowing the ToPA, same as in non-nested virtualization for <=Skylake processors. So we have | mode |----------------------------------------------------------- nested? | system-wide | host-guest ------------+-------------------------------+--------------------------- no | use HPA for tracing | use GPA for tracing | (no EPT) | (EPT is GPA->HPA) ------------+-------------------------------+--------------------------- yes | use GPA for tracing | use nGPA for tracing | (EPT is nGPA->HPA!!) | (EPT is nGPA->HPA, so ok) (for nested, L0 mode of course must be host-guest). If the nested hypervisor wants to use system-wide tracing, it cannot use "use GPA for tracing" because the EPT table doesn't have the right mapping of L1->L0 physical address. So if you want to do system-wide L1 tracing you have to disable EPT for L1, and if you want to do host-guest L1 tracing you have to enable it. Paolo > If yes, what should we do? In patch 9, I pass > though PT MSRs ( IA32_RTIT_* ) to guest.