Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2242184imm; Fri, 7 Sep 2018 13:06:38 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdbtlw18CL/2suR3GsYvrMZ6DYhU6NlXkrB6yEoBPFXCp8H96m3/rhE0Jg03rai1uQx0+Pg/ X-Received: by 2002:a62:1e81:: with SMTP id e123-v6mr10409009pfe.24.1536350797943; Fri, 07 Sep 2018 13:06:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536350797; cv=none; d=google.com; s=arc-20160816; b=SdygVpX/lynAj29hsgqiY8tYPjQeyM94HkUOBE7m3nEFz1TEyHUKzCjs0OHV4+0rWk hINdUlBy5zNlk5rpwfBRvA7z/n+yalHJ+WnX6BxKX5dyFPjjLnRggxu86TtZ650ljft7 TugPr6ZgECkVOXzITk7VwP3WqO7v2u991i2Lgt+r6AfDHtc2+Pbhv2r5MKusRizSrH21 BZ8EdqFzG9hVJt21pYpDf1upc9vISbxLfV/ypaWzV5TZcjjr3Yxbl4IIQWyGiNbGbrXW 5T1p07KhAVOqf57i5B0OCEuDeIT/LK8SpdgZMSXyIpIm51daU6vsxLcj+9tyAGoapjjV QQ7Q== 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=q55E/UguLpiOQc2j90H5AcYS2Th5zIPfYk58oJq/sLk=; b=m9aa47ATznsMWYKKKCr3eNG3Y48YMQEVy3wjWcLEh9Ic6X16enB+aHMJLZBpogsPgQ Ogw6Tq0wqDNSBzfPjOG4U/OtbRsjQoBv6ZSXThqW6theHPWrstoVfh2ehJpIb+xVy1nj yCjYsPHtabXiKFMGdevgXvnud4tQaJjMasWbZJENetyquIbi9mhifv+xmKeXNDMSbAcq TGQX/PDQZe+ipHkY7kD0dp9kZ9ZPCWkC7SfbgYebU2odRCLp+W/oUs8a2G7PKbgcvZW+ v6VQgDyNndvnzaavEZT0ITvcNLobD5zT1iHikMPjkws2ZUQL4P18fqKVjGR3qeF3+J0H 3b5A== 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 e1-v6si9682785pfa.274.2018.09.07.13.06.22; Fri, 07 Sep 2018 13:06:37 -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 S1726599AbeIHArm (ORCPT + 99 others); Fri, 7 Sep 2018 20:47:42 -0400 Received: from mga02.intel.com ([134.134.136.20]:46081 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725987AbeIHArm (ORCPT ); Fri, 7 Sep 2018 20:47:42 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Sep 2018 13:05:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,343,1531810800"; d="scan'208";a="86943329" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.126]) by fmsmga004.fm.intel.com with ESMTP; 07 Sep 2018 13:05:11 -0700 Received: by tassilo.localdomain (Postfix, from userid 1000) id E3336300B65; Fri, 7 Sep 2018 13:05:10 -0700 (PDT) Date: Fri, 7 Sep 2018 13:05:10 -0700 From: Andi Kleen To: "Wang, Wei W" 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: <20180907200510.GR27886@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> <20180907141051.GP27886@tassilo.jf.intel.com> <286AC319A985734F985F78AFA26841F73978F75E@shsmsx102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <286AC319A985734F985F78AFA26841F73978F75E@shsmsx102.ccr.corp.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 > How would you realize the function of saving/restoring the lbr stack on the host? > > Here, we create a perf event on the host (please see guest_lbr_event_create on patch 7), which essentially satisfies all the conditions (e.g. increases cpuc->lbr_users) that are required to have the lbr stack saved/restored on the vCPU switching. > > If we want to stop the host side lbr stack save/restore for the vCPU, we need accordingly to call guest_lbr_event_release (in patch 7) to destroy that perf event (the host doesn't automatically stop saving the lbr stack for the vCPU if that perf event is still there). > > When would you call that release function? (we all know that the lbr doesn't need to be saved when the guest is not using it, but we need to destroy that perf event to achieve "doesn't need to be saved") Maybe set a timer on DEBUGCTL LBR=0 ? A timer would provide hysteresis, so that quick toggles (like in a PMI handler) wouldn't do anything expensive. It needs new interfaces for perf anyways because we need to access the LBR state from the last save. -Andi