Received: by 2002:ab2:1689:0:b0:1f7:5705:b850 with SMTP id d9csp707392lqa; Sat, 27 Apr 2024 23:57:50 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWyoMpI1j/fDPp3He5RgMf6u4X0MNJC9AL8qjHE/wcc6LaFSVRTAg/iLz0IzFG8vIXUWU/InMdrFlwdDXX8L6U2181LN+wVT/tr2QWG6g== X-Google-Smtp-Source: AGHT+IGkVLRzicV4e/EwcTBBazfT/xtbWy5akqEL318CghTb3n8CHFRHDyZ/ewa2qSlUas0sVCfo X-Received: by 2002:a05:6358:4b41:b0:183:f7cb:af75 with SMTP id ks1-20020a0563584b4100b00183f7cbaf75mr8382222rwc.32.1714287470019; Sat, 27 Apr 2024 23:57:50 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1714287469; cv=pass; d=google.com; s=arc-20160816; b=DDeTj85IZGGmZeEFUEQkbNuohK/3qR3JYXUNWS0z+CQtVhQxEw6GdyCFtrNzUfyPjA nx2Y9JYoB+S6uMF87NK0WSTQTkdkf9BfI4nHUFiKWh6IiODSmgQK8ZJtJFXYxPSan80e d81Wt3tYXyQudEwfbIIIF7hlNV14YmUNGCiE8dmARgrdtiybGDFq6KzK3LgUKdrAP2gz uKMJ5DGXy6CS5JOf9IgPcpS/zzsVUSMZNYOZtIa0c7HDprE104i9AUe+ySGCrWwOSdMC /EVNLOTKgwOZgjqbnXghFJBgiae0bKehLeCmEoIs9LYyrTs8hg+KdHyKwrTtENaoUegm AOwA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=9cuP8CZ8oGoSPY1Ii2uXPEpj1n8wUsYSV9WfcYK+Ax0=; fh=GqFci1z9jG/4XTob/L/hm1zFZnzt2eN6UXeVEN0k7Gk=; b=OWqHLOjXRVRKbbkBMb3Bh7NQTaJ8jOCHef38zObtIwzZR8q+edZD7DizoU1tZyivwD /eItn5qKTxUPoQYEYEcclciGYZQqEktXBTX1CaXcWHvyl39etP9VOJxBZvpovxW7Mg93 yIF1QolUe4HHjdrI+tuBh7RRnTYXncmTcgogQnNa9+TLg8mN7pPdqS+6tcaBGI+4aQ+n puTBKhP/UAbqctvOSvFDsuFmccSlakl+gWNOeTmn5TjSjneQCGy8vYCOMBAudUaXZi8S o+YUBc/y3r0mgGWMbDEzoQx7VHKGQrWlA75DwKYoJT+o1qLiS3raV5WSpOPuFA4wawTb NlJQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=WZbkQ2qu; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-161205-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-161205-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id v68-20020a632f47000000b005dcbb9ebe61si17703458pgv.821.2024.04.27.23.57.49 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Apr 2024 23:57:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-161205-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=WZbkQ2qu; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-161205-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-161205-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id D64A428235F for ; Sun, 28 Apr 2024 00:59:09 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8761F1362; Sun, 28 Apr 2024 00:59:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="WZbkQ2qu" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF60764A; Sun, 28 Apr 2024 00:58:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714265939; cv=none; b=RA9CjTt3uN75CaSoqnv3xinM8auaMK7SInkM/ZX3fR94BeiF86oSXXZUXksHFlTHtYdRWqCShCBGRD6HLe2oEqnoEVrqu9v5C5zS/jeLm3MpeW2qLMbrEGfuVTDP4roeW5T7mBn6Eh66PgrlHXEjUAey9E3iVMkrtPcfvWdGWDg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714265939; c=relaxed/simple; bh=sruZuykMgwQNrqDsSrjLsyhTwtcH6jJaF/1elUBTY4o=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=oJEjg8UYblshmzYK868Gw7Opr1YlKw+UXhQFJO3Jb2mJgEwVHGD80XET0WxGT1cGTn6V/N4YKUt6tJdgLDEwvSodrH8HF+nRoCqK3L8pzUe0w5u9//u/OL53D4O3i0nn7LdBRClnNENjS45q4xSYqZR369MTbh8vqKX9lNNkdwA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=WZbkQ2qu; arc=none smtp.client-ip=198.175.65.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1714265938; x=1745801938; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=sruZuykMgwQNrqDsSrjLsyhTwtcH6jJaF/1elUBTY4o=; b=WZbkQ2qunJKXyRHUKZ5cF2TwWCiNvHhfjzXsTYu1gilfOP2HKOQQlbV5 +aZFtsr95MX4pGP5QCyB7/oXXOgZWCb0yV2MPIY5ZLqzTM1CrjwYhltLz OviE7Yag7zTuCtxc06Z6OmlO8bYP61oSu25IeStQ1HfVHlU1lJbArbvQH HSm/vJBVXuUoe4AdS+INvfMKWKMlXOJ7zg0WRcJTk5TrvV1MJqN8BDspf Y9TaQ6/33NBidnDlqLdUSyVmicwHAoWLF7Tukruo6LJtfvGoO8zNpkCW0 7MpvANHuym5OQXdd9z/rgBC7rW7ZxxKkfZO6qOiQfF0lZvI1tv6sNnAaT g==; X-CSE-ConnectionGUID: c7P+zrYJRPeoG3GMLCd9+g== X-CSE-MsgGUID: KLLNWMcZTyuAv3FY7qv+1A== X-IronPort-AV: E=McAfee;i="6600,9927,11057"; a="9827167" X-IronPort-AV: E=Sophos;i="6.07,236,1708416000"; d="scan'208";a="9827167" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2024 17:58:57 -0700 X-CSE-ConnectionGUID: 1ADNkzFRT7KuUnFBhO/zJg== X-CSE-MsgGUID: fFQsozLAQF6AxccK77EbFA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,236,1708416000"; d="scan'208";a="25642447" Received: from dapengmi-mobl1.ccr.corp.intel.com (HELO [10.124.245.127]) ([10.124.245.127]) by orviesa010-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2024 17:58:53 -0700 Message-ID: Date: Sun, 28 Apr 2024 08:58:50 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 23/41] KVM: x86/pmu: Implement the save/restore of PMU state for Intel CPU To: Mingwei Zhang , Sean Christopherson Cc: Kan Liang , maobibo , Xiong Zhang , pbonzini@redhat.com, peterz@infradead.org, kan.liang@intel.com, zhenyuw@linux.intel.com, jmattson@google.com, kvm@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, zhiyuan.lv@intel.com, eranian@google.com, irogers@google.com, samantha.alt@intel.com, like.xu.linux@gmail.com, chao.gao@intel.com References: <6af2da05-cb47-46f7-b129-08463bc9469b@linux.intel.com> <42acf1fc-1603-4ac5-8a09-edae2d85963d@linux.intel.com> <77913327-2115-42b5-850a-04ef0581faa7@linux.intel.com> <5f5bcbc0-e2ef-4232-a56a-fda93c6a569e@linux.intel.com> Content-Language: en-US From: "Mi, Dapeng" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4/27/2024 11:04 AM, Mingwei Zhang wrote: > On Fri, Apr 26, 2024 at 12:46 PM Sean Christopherson wrote: >> On Fri, Apr 26, 2024, Kan Liang wrote: >>>> Optimization 4 >>>> allows the host side to immediately profiling this part instead of >>>> waiting for vcpu to reach to PMU context switch locations. Doing so >>>> will generate more accurate results. >>> If so, I think the 4 is a must to have. Otherwise, it wouldn't honer the >>> definition of the exclude_guest. Without 4, it brings some random blind >>> spots, right? >> +1, I view it as a hard requirement. It's not an optimization, it's about >> accuracy and functional correctness. > Well. Does it have to be a _hard_ requirement? no? The irq handler > triggered by "perf record -a" could just inject a "state". Instead of > immediately preempting the guest PMU context, perf subsystem could > allow KVM defer the context switch when it reaches the next PMU > context switch location. > > This is the same as the preemption kernel logic. Do you want me to > stop the work immediately? Yes (if you enable preemption), or No, let > me finish my job and get to the scheduling point. > > Implementing this might be more difficult to debug. That's my real > concern. If we do not enable preemption, the PMU context switch will > only happen at the 2 pairs of locations. If we enable preemption, it > could happen at any time. IMO I don't prefer to add a switch to enable/disable the preemption. I think current implementation is already complicated enough and unnecessary to introduce an new parameter to confuse users. Furthermore, the switch could introduce an uncertainty and may mislead the perf user to read the perf stats incorrectly.  As for debug, it won't bring any difference as long as no host event is created. > >> What _is_ an optimization is keeping guest state loaded while KVM is in its >> run loop, i.e. initial mediated/passthrough PMU support could land upstream with >> unconditional switches at entry/exit. The performance of KVM would likely be >> unacceptable for any production use cases, but that would give us motivation to >> finish the job, and it doesn't result in random, hard to diagnose issues for >> userspace. > That's true. I agree with that. > >>>> Do we want to preempt that? I think it depends. For regular cloud >>>> usage, we don't. But for any other usages where we want to prioritize >>>> KVM/VMM profiling over guest vPMU, it is useful. >>>> >>>> My current opinion is that optimization 4 is something nice to have. >>>> But we should allow people to turn it off just like we could choose to >>>> disable preempt kernel. >>> The exclude_guest means everything but the guest. I don't see a reason >>> why people want to turn it off and get some random blind spots.