Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp4028014pxb; Fri, 11 Feb 2022 13:21:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJwf2hTMHHUemxYXBiOrhmppN13z965sSZSD8oogxImWTz2ZGIXduoUkdizHO+etQRLVKLcH X-Received: by 2002:a05:6402:2802:: with SMTP id h2mr3951896ede.255.1644614480366; Fri, 11 Feb 2022 13:21:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644614480; cv=none; d=google.com; s=arc-20160816; b=NdwVuhv5IZ1IAOdYOkLXtd2bs4CP6lmPUR0s8Bfqn28j8Ys35yA2oHXxVTPAZTEcKd Mu1LfywMJGlY0+ZI/korjYklJ909MJ/K3zUAbC3EOv32MS+X+5WyhQ6KeKZH+R3u6O3t 0HuYwa97OOGUa/LjtO+X2mVrtGW+rQY8cgJSn0OdjcynG50ZZcsyWcz7bBtbst3tYTnw 31IP72WU49+EWw9EaTzg4vuJPVeqX8EHvSaIicPIf7agUxBF6gwdvvmlwF2l4kdaPew3 FN6JSKKncSqGU+cfzg6c2p847UvYqix08xDW+jMrGEurIsUfZti9LNmE7ub1QGPeOOH9 BBeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=4ezZKO/sKq+udK33lTp4upgqqXdLXoYIeBL3uXEwM8c=; b=Jw9aynRLwYOIw/ukC1PEXZt6aoLv2HDvnjD82SXFtW2hflGUv5JD8JezUbSJiKYjsN OdGfRKi0MCQB32Pwa/y1YuOI2UHaeYbJ43mv70DQ4kgXnwYykDedWAOzOnLBS4LvNS1A yz4uVvqx0r4KQq79+OfQE/0zn1SqYR7dyFnVL3wo33iczb/+9kLddDzbAHJFHSFOpbrV XVEeDT3hDPDSaHC1fiEF4XY+KJStJukcLjpnQEuzzRMZ435VviRVxZycllPkvjJU+huP iZw6nwT8tTGcjsbE6X6y6/ZSuxk/NlZeLrtVegj0Pyz2MCP+zcdcvxTbYT4gzKvL0X84 wJ9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=jB6g23e5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ss23si13260512ejc.793.2022.02.11.13.20.53; Fri, 11 Feb 2022 13:21:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=jB6g23e5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231338AbiBKSJH (ORCPT + 99 others); Fri, 11 Feb 2022 13:09:07 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:53394 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343603AbiBKSJF (ORCPT ); Fri, 11 Feb 2022 13:09:05 -0500 Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C71D6CEC for ; Fri, 11 Feb 2022 10:09:03 -0800 (PST) Received: by mail-oo1-xc2e.google.com with SMTP id o128-20020a4a4486000000b003181707ed40so11194770ooa.11 for ; Fri, 11 Feb 2022 10:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4ezZKO/sKq+udK33lTp4upgqqXdLXoYIeBL3uXEwM8c=; b=jB6g23e56s6dlqAXLs7ZEmhT9fEgfh3KilZ2gYZFLE65prmgzUU8dBD29sSysYRq+D GW6fDxC9rgaZjkWi2Y95CbiiK87nu+2uFUOTUfdJ+iPDVqUcpfqVyu+XZkM3rOM0MXUm qBwUHSvY8zVLycV3H+FyQJ5vyyzGZLFy3V4sZGXfUPy4puPy7XYfRdBskcyXdu8wI4dg TL4ScxcQDo9XV2BxdgzdEvWAMIfn1GEhHrv7v2qK2OcFS3f/VRHiwb/jtt7FtPxYpeqL OQW9zCqltpG0LEX4pWnJpP45+guJuWrYnJcwTHgA/0cqvjkQqGSpwSXKWuqd7GQINsvO 9j8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4ezZKO/sKq+udK33lTp4upgqqXdLXoYIeBL3uXEwM8c=; b=jEJKchS0ay25XTeut/YyGLakVGzCSgdNsE+hmLiAQYkqkJzY7sjWJmtu/yvQzsC2zN AwbeSRg6JEk2dEp70y6xcM8uJdN28yDYNFevuNGgI4JxGax1xkBWjP5ERhY/6nRI/BJd JID3SSqghrSOUElegAUQQAhC317VnEsu/hAVcQg5h3sLOmEkknesKLEHPPejtbnQDgli ylyaibHHhfJB8SlLmd9LIbzVg5MH9OW9jzFzBga8WHc9CDz8+I5zqnJ2UqVewawdPGHQ 2qVqxpWWqZjqnsHKjr5jLNRA1i4dIBIznjs5wEtyJt63u7wv9GTu563knAtqQbJPii3c X7IA== X-Gm-Message-State: AOAM530Gs3+5NJsArQK8UTHxTX8vfyr3Gbpp+W4akP8tOifdVsNgkxg3 uy7qgjfwC0SZ1KHGx4152B6iLZWjtRrfZzSNmHjJHw== X-Received: by 2002:a05:6871:581:: with SMTP id u1mr529381oan.139.1644602942929; Fri, 11 Feb 2022 10:09:02 -0800 (PST) MIME-Version: 1.0 References: <20220117085307.93030-1-likexu@tencent.com> <20220117085307.93030-3-likexu@tencent.com> <20220202144308.GB20638@worktop.programming.kicks-ass.net> <69c0fc41-a5bd-fea9-43f6-4724368baf66@intel.com> <67a731dd-53ba-0eb8-377f-9707e5c9be1b@intel.com> <7b5012d8-6ae1-7cde-a381-e82685dfed4f@linux.intel.com> <6afcec02-fb44-7b72-e527-6517a94855d4@linux.intel.com> In-Reply-To: <6afcec02-fb44-7b72-e527-6517a94855d4@linux.intel.com> From: Jim Mattson Date: Fri, 11 Feb 2022 10:08:51 -0800 Message-ID: Subject: Re: [PATCH kvm/queue v2 2/3] perf: x86/core: Add interface to query perfmon_event_map[] directly To: "Liang, Kan" Cc: David Dunn , Dave Hansen , Peter Zijlstra , Like Xu , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Like Xu , Stephane Eranian Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 11, 2022 at 6:11 AM Liang, Kan wrote: > > > > On 2/10/2022 2:55 PM, David Dunn wrote: > > Kan, > > > > On Thu, Feb 10, 2022 at 11:46 AM Liang, Kan wrote: > > > >> No, we don't, at least for Linux. Because the host own everything. It > >> doesn't need the MSR to tell which one is in use. We track it in an SW way. > >> > >> For the new request from the guest to own a counter, I guess maybe it is > >> worth implementing it. But yes, the existing/legacy guest never check > >> the MSR. > > > > This is the expectation of all software that uses the PMU in every > > guest. It isn't just the Linux perf system. > > > > The KVM vPMU model we have today results in the PMU utilizing software > > simply not working properly in a guest. The only case that can > > consistently "work" today is not giving the guest a PMU at all. > > > > And that's why you are hearing requests to gift the entire PMU to the > > guest while it is running. All existing PMU software knows about the > > various constraints on exactly how each MSR must be used to get sane > > data. And by gifting the entire PMU it allows that software to work > > properly. But that has to be controlled by policy at host level such > > that the owner of the host knows that they are not going to have PMU > > visibility into guests that have control of PMU. > > > > I think here is how a guest event works today with KVM and perf subsystem. > - Guest create an event A > - The guest kernel assigns a guest counter M to event A, and config > the related MSRs of the guest counter M. > - KVM intercepts the MSR access and create a host event B. (The > host event B is based on the settings of the guest counter M. As I said, > at least for Linux, some SW config impacts the counter assignment. KVM > never knows it. Event B can only be a similar event to A.) > - Linux perf subsystem assigns a physical counter N to a host event > B according to event B's constraint. (N may not be the same as M, > because A and B may have different event constraints) > > As you can see, even the entire PMU is given to the guest, we still > cannot guarantee that the physical counter M can be assigned to the > guest event A. All we know about the guest is that it has programmed virtual counter M. It seems obvious to me that we can satisfy that request by giving it physical counter M. If, for whatever reason, we give it physical counter N isntead, and M and N are not completely fungible, then we have failed. > How to fix it? The only thing I can imagine is "passthrough". Let KVM > directly assign the counter M to guest. So, to me, this policy sounds > like let KVM replace the perf to control the whole PMU resources, and we > will handover them to our guest then. Is it what we want? We want PMU virtualization to work. There are at least two ways of doing that: 1) Cede the entire PMU to the guest while it's running. 2) Introduce a new "ultimate" priority level in the host perf subsystem. Only KVM can request events at the ultimate priority, and these requests supersede any other requests. Other solutions are welcome. > Thanks, > Kan