Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1966540imm; Fri, 7 Sep 2018 08:48:47 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaoZ/gw4BVH8h1uc7OO/ZNRANHjUvLz/poL41rXJLT1mCDnDKTmcRZVFpZq4f0CIkngyxk4 X-Received: by 2002:a63:225f:: with SMTP id t31-v6mr8848279pgm.275.1536335327364; Fri, 07 Sep 2018 08:48:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536335327; cv=none; d=google.com; s=arc-20160816; b=1D4PgKYq17UmHnGRB8gTwt9WD76NNfSKq7Ss5L8RKp5AIptmzNBOo7DQbbp6HYWp/Y BNlviVTEbD91rSm+LCdozCsPZ4bJVBQg/N+16s1gQdldPexFyN0AXEUcm2EC8TGDxwqV Ir1rQqmgSxLV1Or7n7YC/0ulhuEc/6kCwoy9hrJTzkvCy/oM8o6eiW+rhr3Gq0IPhvbc fMgmgDs55/QJ4mT1jufwWXyodHO5Dtctl/n+w1mIPqO2NEUBzIkLANi5lNqrBmeE6n6g 9/iWXQyMwn4Du4+2U/MZW5/LlClmb8O8qh//vU9dBS0SMpHKvFn23Dgnc/Zzym/uuCyD m6UQ== 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=fTVuWQwhOamryc6herFEPsSqOj20GfTBWSOlAJllehs=; b=gURxI6AP+6Qx2yVGniZp9AZ3kPIeVcOsHuP+HHyGfB7EL8Cp+hkZsAYtMpE7yszymA tl+dLKeCp38ExJWfI+v0tKIHd4I7BtzlqluUZik5MYp/FZnbwhc3XwW8+58bA97NtV1g ySVe3ENsl2UZb+CQWpJMUM0o7LbyqCO+Mgp0psho4IavMJ1UNQuERwophjHzdl6flBKP 2O/WnekuSVR9dmHS7kTocXJX1Csl8HIe4vs6GDsrXapZ5U3nFNycgJfJaU2EGG9rNtIE h31RfXP4rQpJUKcvLFQOfHwsFdEWc2iHkiaLaIwaai+4fRmKIgLvNMRdW8/LW2YOQh2R auog== 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 w12-v6si7882291pld.362.2018.09.07.08.48.31; Fri, 07 Sep 2018 08:48:47 -0700 (PDT) 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 S1729006AbeIGSv7 (ORCPT + 99 others); Fri, 7 Sep 2018 14:51:59 -0400 Received: from mga11.intel.com ([192.55.52.93]:23201 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727820AbeIGSv7 (ORCPT ); Fri, 7 Sep 2018 14:51:59 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Sep 2018 07:10:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,342,1531810800"; d="scan'208";a="261570819" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.126]) by fmsmga006.fm.intel.com with ESMTP; 07 Sep 2018 07:10:51 -0700 Received: by tassilo.localdomain (Postfix, from userid 1000) id 8928E300B65; Fri, 7 Sep 2018 07:10:51 -0700 (PDT) Date: Fri, 7 Sep 2018 07:10:51 -0700 From: Andi Kleen To: Wei Wang Cc: "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , "pbonzini@redhat.com" , "Liang, Kan" , "peterz@infradead.org" , "mingo@redhat.com" , "rkrcmar@redhat.com" , "Xu, Like" Subject: Re: [PATCH v2 6/8] perf/x86/intel/lbr: guest requesting KVM for lbr stack save/restore Message-ID: <20180907141051.GP27886@tassilo.jf.intel.com> References: <1536233456-12173-1-git-send-email-wei.w.wang@intel.com> <1536233456-12173-7-git-send-email-wei.w.wang@intel.com> <20180907032707.GN27886@tassilo.jf.intel.com> <5B920B96.6080803@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B920B96.6080803@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 > This could achieve the above #1, but how would it solve #2 above? That is, > after the guest uses the lbr feature for a while, the lbr stack has been > passed through, then the guest doesn't use lbr any more, but the vCPU will > still save/restore on switching? If nothing accesses the MSR LBRs after a context switch in the guest nothing gets saved/restored due to: > > Also when the LBRs haven't been set to direct access the state doesn't > > need to be saved. -Andi