From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42612) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evQZh-0002dz-VN for qemu-devel@nongnu.org; Mon, 12 Mar 2018 12:45:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1evQZd-0000Jn-TO for qemu-devel@nongnu.org; Mon, 12 Mar 2018 12:45:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58178) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1evQZd-0000IJ-L1 for qemu-devel@nongnu.org; Mon, 12 Mar 2018 12:45:21 -0400 Date: Mon, 12 Mar 2018 13:45:17 -0300 From: Eduardo Habkost Message-ID: <20180312164517.GS3417@localhost.localdomain> References: <1520182116-16485-1-git-send-email-luwei.kang@intel.com> <20180309191048.GA28578@localhost.localdomain> <82D7661F83C1A047AF7DC287873BF1E167EF4877@SHSMSX101.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82D7661F83C1A047AF7DC287873BF1E167EF4877@SHSMSX101.ccr.corp.intel.com> Subject: Re: [Qemu-devel] [PATCH v4 1/2] i386: Add Intel Processor Trace feature support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Kang, Luwei" Cc: "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "mtosatti@redhat.com" , Chao Peng , "pbonzini@redhat.com" , "rth@twiddle.net" On Mon, Mar 12, 2018 at 09:07:41AM +0000, Kang, Luwei wrote: > > > + > > > + if (!eax_0 || > > > + ((ebx_0 & INTEL_PT_MINIMAL_EBX) != INTEL_PT_MINIMAL_EBX) || > > > + ((ecx_0 & INTEL_PT_MINIMAL_ECX) != INTEL_PT_MINIMAL_ECX) || > > > + ((eax_1 & INTEL_PT_MTC_BITMAP) != INTEL_PT_MTC_BITMAP) || > > > + ((eax_1 & INTEL_PT_ADDR_RANGES_NUM_MASK) < > > > + INTEL_PT_ADDR_RANGES_NUM) || > > > + ((ebx_1 & (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP)) != > > > + (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP))) { > > > > I still don't see a check to ensure the host has bit 31 on ecx_0 set to 0, as I mentioned when reviewing v3. > > Hi Eduardo, > Thanks for the code review. I don't quite understand here why bit31 must same with host (meaning we must reject a host > where ecx_0 & (1 << 31) is set). If the guest sees the bit set to 0, it will expect IP payloads with RIP values, but the host CPU will generate IP payloads with LIP values. I assume KVM won't do RIP<->LIP translation on the packets generated by the host before the guest sees them, will it? > Do you mean PT must be disabled in guest when host bit31 is set? > Bit 31: If 1, generated packets which contain IP payloads have LIP values, which include the CS base component. > I can't find any special on this bit. Could you help clarify? As far as I understand, this bit is special because KVM can't emulate a value that's different from the host. -- Eduardo