Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7547013imu; Thu, 27 Dec 2018 23:57:56 -0800 (PST) X-Google-Smtp-Source: AFSGD/VBya8W3Ul3sv9qZgksbH07+NHuqbnTdvi+bVEwsWMYvKHkX1NZ+AqYIFUQ18Od0S5i2xMe X-Received: by 2002:a62:b80a:: with SMTP id p10mr27036659pfe.32.1545983876368; Thu, 27 Dec 2018 23:57:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545983876; cv=none; d=google.com; s=arc-20160816; b=Zk39whNC1zaRCnJEHcMRYgsAr1mAjmwZ+LuGNlvqCOJlS/xRrOI8CFizvX7lAFJYOX p7MEzQU9EGmsNu/zMnO9x+NpxQf26w5RZ2hv2vL/rtRAXfewr7IFqYglsyCCMCFDHFqq 3RIaC5bqGIwcLV4jAXaR24yT+UN076VDDhGf15J/ipD1Ol2NE8u1wJV4ItNaPSK3Z/Lm EwhLLcVpQJCLa7Efj3lNV2h2bFT6lJXKHCdNvFFO0nnQnhVFiwE0JOwG1uadP0WxqmBF LI4LWGHQDRArm6XTNEsHR23cjvOiHvgQvq8+Vxa15OMii48RdoxBE41KUtukgKC3jDib 3Arw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=paFx5y6u2fUJU4z3bz9NVDhqY9FD7tkD4nQz1YmhBM0=; b=N4da4PCdf/VRTMSE9EP6KEa+ilr52Hr3UpQvw/thdvjREH79UTyH3TAnLPoo/aa/z8 ggeAx+bfuWhs9i/LlCUOYxDndqFn5TW8o7FX8gw4RhDwV8rfEwGI2PAAk/n7NUTDYHGU JoTiIUcxqDIUgTERR4WK+mQ2Zsx2wTCIzsP0YwdEkAMrngNI9XIi8V7EVGnoyLtLpaeb ewOSviyYFhEzyst6ZKY/A81OkhvFOPKH9JVDNaloQXkG8oNF3CwZF+MJCBWCcDFqJXGa orwHFYyHMRc/7m00wbI3AQ9IBj/OwLbLniiKQtWv/ndiITegStDZ9yB/NbVdudwXvdOr 7b1w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k11si5896772pgh.132.2018.12.27.23.57.40; Thu, 27 Dec 2018 23:57:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730043AbeL0UvG (ORCPT + 99 others); Thu, 27 Dec 2018 15:51:06 -0500 Received: from mga12.intel.com ([192.55.52.136]:45954 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727940AbeL0UvF (ORCPT ); Thu, 27 Dec 2018 15:51:05 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Dec 2018 12:51:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,406,1539673200"; d="scan'208";a="133288614" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.137]) by fmsmga001.fm.intel.com with ESMTP; 27 Dec 2018 12:51:04 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id A537C300B65; Thu, 27 Dec 2018 12:51:04 -0800 (PST) Date: Thu, 27 Dec 2018 12:51:04 -0800 From: Andi Kleen To: Wei Wang Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, pbonzini@redhat.com, peterz@infradead.org, kan.liang@intel.com, mingo@redhat.com, rkrcmar@redhat.com, like.xu@intel.com, jannh@google.com, arei.gonglei@huawei.com Subject: Re: [PATCH v4 10/10] KVM/x86/lbr: lazy save the guest lbr stack Message-ID: <20181227205104.GG25620@tassilo.jf.intel.com> References: <1545816338-1171-1-git-send-email-wei.w.wang@intel.com> <1545816338-1171-11-git-send-email-wei.w.wang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1545816338-1171-11-git-send-email-wei.w.wang@intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks. This looks a lot better than the earlier versions. Some more comments. On Wed, Dec 26, 2018 at 05:25:38PM +0800, Wei Wang wrote: > When the vCPU is scheduled in: > - if the lbr feature was used in the last vCPU time slice, set the lbr > stack to be interceptible, so that the host can capture whether the > lbr feature will be used in this time slice; > - if the lbr feature wasn't used in the last vCPU time slice, disable > the vCPU support of the guest lbr switching. time slice is the time from exit to exit? This might be rather short in some cases if the workload does a lot of exits (which I would expect PMU workloads to do) Would be better to use some explicit time check, or at least N exits. > > Upon the first access to one of the lbr related MSRs (since the vCPU was > scheduled in): > - record that the guest has used the lbr; > - create a host perf event to help save/restore the guest lbr stack if > the guest uses the user callstack mode lbr stack; This is a bit risky. It would be safer (but also more expensive) to always safe even for any guest LBR use independent of callstack. Otherwise we might get into a situation where a vCPU context switch inside the guest PMI will clear the LBRs before they can be read in the PMI, so some LBR samples will be fully or partially cleared. This would be user visible. In theory could try to detect if the guest is inside a PMI and save/restore then, but that would likely be complicated. I would save/restore for all cases. > +static void > +__always_inline vmx_set_intercept_for_msr(unsigned long *msr_bitmap, u32 msr, > + int type, bool value); __always_inline should only be used if it's needed for functionality, or in a header. The rest looks good. -Andi