Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp123356imu; Thu, 3 Jan 2019 15:31:13 -0800 (PST) X-Google-Smtp-Source: ALg8bN6brwFV4xZxo5FJst1A5Ny3OZUc+oQvzM1x2392byMHVAcaquYPES67S3uMf7ytBGkaHpuL X-Received: by 2002:a63:7418:: with SMTP id p24mr18884818pgc.196.1546558273435; Thu, 03 Jan 2019 15:31:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546558273; cv=none; d=google.com; s=arc-20160816; b=OKbpHwKdDY6zN4RqcQOwpCrhbHb4Ez5jxalmNGhRq1w0CCoQu//4pWSn0EEV0obkWt OB11hDoDqEV2phyPDCqmmZSPm6+oqWg12Ju3R5L9M26f0AvNJv9sA+T+PyuXuFuVHFx9 X3AfCMd9P1fK4SYIbR0oPV6fpVE08TIUZVmwvu8U+32m6ctvW4EHJxgczX4KhjEXUl73 zyIfR87vyoKfjvzyaIhpiJPf6QhewygZcy87xMQ9qjSbgt3EY+zNpUKBtBZW6d3SrJOJ w/Ef+yNvlXbSHT/1mO4eCrKevSXpK2Fl2WzwIyA7A24unJLSMoingPxhwIczacJxcYx8 r+VQ== 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=Q22SJx0/mGFYh9bWsbR7pfjz/K8vZOs9FObBvLpYDOQ=; b=RAB9JEF2r0qRQcnAnHgx4oEWLggtszQII+1IuuWoxsf/VSr8EGawKpF24egqj9qUIY 2sVeEjeZeHRdh2FF9aUcUEHKHptG6yY4B4PWgG8G4R1CoftFWqBwtWWv0V3W8PuVsmby RtyrFCiQN/BN2CEAytTGUxnI1Mss1URvAsIBBYyPVu7BmtH2/jSfX7I02nRVm8l36Zbb e1WIy1qMJ3faguuSr4b8BVwX68NMRBUmj4EeZF1v5lip9QgH5XapcbcDzn3BuESmS1jK 8YF3W4jHTMzUBwIoym0HbGUx9wVLF7R1KkbYuU5thH+7o1gGC9iakHlEScKbk1DaoLEV 2Tbw== 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 v141si56417102pfc.260.2019.01.03.15.30.58; Thu, 03 Jan 2019 15:31:13 -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 S1732543AbfACRSj (ORCPT + 99 others); Thu, 3 Jan 2019 12:18:39 -0500 Received: from mga12.intel.com ([192.55.52.136]:28137 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730864AbfACRSj (ORCPT ); Thu, 3 Jan 2019 12:18:39 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jan 2019 09:18:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,435,1539673200"; d="scan'208";a="113926122" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.137]) by fmsmga008.fm.intel.com with ESMTP; 03 Jan 2019 09:18:37 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id ABC33301B2E; Thu, 3 Jan 2019 09:18:38 -0800 (PST) Date: Thu, 3 Jan 2019 09:18:38 -0800 From: Andi Kleen To: Jim Mattson Cc: Wei Wang , LKML , kvm list , Paolo Bonzini , Peter Zijlstra , Kan Liang , Ingo Molnar , Radim =?utf-8?B?S3LEjW3DocWZ?= , like.xu@intel.com, Jann Horn , arei.gonglei@huawei.com Subject: Re: [PATCH v4 04/10] KVM/x86: intel_pmu_lbr_enable Message-ID: <20190103171838.GB6118@tassilo.jf.intel.com> References: <1545816338-1171-1-git-send-email-wei.w.wang@intel.com> <1545816338-1171-5-git-send-email-wei.w.wang@intel.com> <5C2DB81F.3000906@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 > Yes, but then what happens? > > Fast forward to, say, 2021. You're decommissioning all Broadwell > servers in your data center. You have to migrate the running VMs off > of those Broadwell systems onto newer hardware. But, with the current > implementation, the migration cannot happen. So, what do you do? I > suppose you just never enable the feature in the first place. Right? There would in theory ways to handle this. LBRs are normally not required for running correctly, they're not like instructions, so it would be actually quite reasonable to just return 0 and ignore writes for incompatible machines for them. Your profilers might return some bogus data, but that is normally acceptable. In some cases it might be also possible to emulate LBRs of different types, but I don't think it would be worth the effort. Yes, but the patches don't do this, so right now you should only enable it when all systems in your migration pool have compatible LBRs. -Andi