From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F4B0C2D0DB for ; Tue, 28 Jan 2020 18:33:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 50E35207FD for ; Tue, 28 Jan 2020 18:33:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726605AbgA1Sdq (ORCPT ); Tue, 28 Jan 2020 13:33:46 -0500 Received: from mga02.intel.com ([134.134.136.20]:13778 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726486AbgA1Sdq (ORCPT ); Tue, 28 Jan 2020 13:33:46 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jan 2020 10:33:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,374,1574150400"; d="scan'208";a="376526931" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.202]) by orsmga004.jf.intel.com with ESMTP; 28 Jan 2020 10:33:45 -0800 Date: Tue, 28 Jan 2020 10:33:45 -0800 From: Sean Christopherson To: Jim Mattson Cc: Nadav Amit , Aaron Lewis , kvm list , Paolo Bonzini , Liran Alon Subject: Re: [kvm-unit-tests PATCH v3] x86: Add RDTSC test Message-ID: <20200128183345.GB18652@linux.intel.com> References: <20191202204356.250357-1-aaronlewis@google.com> <4EFDEFF2-D1CD-4AF3-9EF8-5F160A4D93CD@gmail.com> <20200124233835.GT2109@linux.intel.com> <1A882E15-4F22-463E-AD03-460FA9251489@gmail.com> <436117EB-5017-4FF0-A89B-16B206951804@gmail.com> <20200127205606.GC2523@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, Jan 28, 2020 at 09:59:45AM -0800, Jim Mattson wrote: > On Mon, Jan 27, 2020 at 12:56 PM Sean Christopherson > wrote: > > > > On Mon, Jan 27, 2020 at 11:24:31AM -0800, Jim Mattson wrote: > > > On Sun, Jan 26, 2020 at 8:36 PM Nadav Amit wrote: > > > > > > > > > On Jan 26, 2020, at 2:06 PM, Jim Mattson wrote: > > > > > > > > > > If I had to guess, you probably have SMM malware on your host. Remove > > > > > the malware, and the test should pass. > > > > > > > > Well, malware will always be an option, but I doubt this is the case. > > > > > > Was my innuendo too subtle? I consider any code executing in SMM to be malware. > > > > SMI complications seem unlikely. The straw that broke the camel's back > > was a 1152 cyle delta, presumably the other failing runs had similar deltas. > > I've never benchmarked SMI+RSM, but I highly doubt it comes anywhere close > > to VM-Enter/VM-Exit's super optimized ~400 cycle round trip. E.g. I > > wouldn't be surprised if just SMI+RSM is over 1500 cycles. > > Good point. What generation of hardware are you running on, Nadav? Skylake. > > > > Interestingly, in the last few times the failure did not reproduce. Yet, > > > > thinking about it made me concerned about MTRRs configuration, and that > > > > perhaps performance is affected by memory marked as UC after boot, since > > > > kvm-unit-test does not reset MTRRs. > > > > > > > > Reading the variable range MTRRs, I do see some ranges marked as UC (most of > > > > the range 2GB-4GB, if I read the MTRRs correctly): > > > > > > > > MSR 0x200 = 0x80000000 > > > > MSR 0x201 = 0x3fff80000800 > > > > MSR 0x202 = 0xff000005 > > > > MSR 0x203 = 0x3fffff000800 > > > > MSR 0x204 = 0x38000000000 > > > > MSR 0x205 = 0x3f8000000800 > > > > > > > > Do you think we should set the MTRRs somehow in KVM-unit-tests? If yes, can > > > > you suggest a reasonable configuration? > > > > > > I would expect MTRR issues to result in repeatable failures. For > > > instance, if your VMCS ended up in UC memory, that might slow things > > > down quite a bit. But, I would expect the VMCS to end up at the same > > > address each time the test is run. > > > > Agreed on the repeatable failures part, but putting the VMCS in UC memory > > shouldn't affect this type of test. The CPU's internal VMCS cache isn't > > coherent, and IIRC isn't disabled if the MTRRs for the VMCS happen to be > > UC. > > But the internal VMCS cache only contains selected fields, doesn't it? > Uncached fields would have to be written to memory on VM-exit. Or are > all of the mutable fields in the internal VMCS cache? Hmm. I can neither confirm nor deny? The official Intel response to this would be "it's microarchitectural". I'll put it this way: it's in Intel's best interest to minimize the latency of VMREAD, VMWRITE, VM-Enter and VM-Exit.