From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7279C433F5 for ; Wed, 2 Feb 2022 22:35:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347927AbiBBWf7 (ORCPT ); Wed, 2 Feb 2022 17:35:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41344 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233105AbiBBWf5 (ORCPT ); Wed, 2 Feb 2022 17:35:57 -0500 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78486C06173B for ; Wed, 2 Feb 2022 14:35:57 -0800 (PST) Received: by mail-pj1-x102b.google.com with SMTP id m7so711719pjk.0 for ; Wed, 02 Feb 2022 14:35:57 -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=DOJciJmMfKX59zirYC4fedok2G+mCB9M97xtePEyCxs=; b=tJ7DSie/k3qorNqByfiltFBEY6Y41g7j+9qFoVXSAAdu4Z7iqfJTcY36zypmO6fDdd hsC+DfkV6B0CDVo67a6pN73X/pqTlU3X1Ha93jOGt+lhyp16jiKeT7gSyv9SeGpH1TMZ hM/lshWwBazpNPxZnPh+GSblyPU1R3ck4BanyWlqjEI1v9iEBBxfU6eL4bHjaDEymnQZ flqoFHA6uVLEV76Aqw8D1lcQT/EKFRvuTRE5e4Q1LoPtjBJtryRD5pImnyEju/oi+OgL tFNdle6DCa+bbFl2JRMi0cioiS/+J3SmpWlOj8TmdkQL/XOR40RadfN4a5VUncodUv3Z qkIQ== 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=DOJciJmMfKX59zirYC4fedok2G+mCB9M97xtePEyCxs=; b=ovUEGVhAtg+JeoCKa5FqyjeZOAF+EG5lyW/jwbq/Fxw3mY2eIz6ckB6hWq5gUI6/UI sfNc+Lo4Kt+XzrJbwew9Us3mef3AouqbB5+uxcuo8BXgLbT/vDWuCCYruskjVqmZt+iF CByO0OvSEO0A5j+PCga25yz59zCBU+Dr8kTZ58y9xwc5hFEHAat+A7+4IKxRlXWuW4Z3 9RatIeYdUVeKbwSgK0fLCStOhUs03A01NLZ2I6SEm7fO7Zm/FpXn0a0ihx1rrIJsSTcY 8Kd13KbqK/i9lqs1/HS8uCgEvKbnHeYzBYlBD2at/BTqOeYMSLPQurkwFPzAQSwQfHZR 57pg== X-Gm-Message-State: AOAM533ot+1sMpV1i0d8/2mP/7Ooutqxige3vll2CTiwoRafXmG8gTlC oxHnBeW2NrvVYyfjpgLnhEsitc/74HqKsDEkb5hObw== X-Google-Smtp-Source: ABdhPJyGltNN9hECUX69y3THPARvb7JMjzrCnjnInjkdQNfNbbtYS81tdnjKa0L2nBzfQwF7pDIVjj6A9ASKEZzbnfQ= X-Received: by 2002:a17:90b:146:: with SMTP id em6mr10579169pjb.214.1643841356497; Wed, 02 Feb 2022 14:35:56 -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> In-Reply-To: <20220202144308.GB20638@worktop.programming.kicks-ass.net> From: Jim Mattson Date: Wed, 2 Feb 2022 14:35:45 -0800 Message-ID: Subject: Re: [PATCH kvm/queue v2 2/3] perf: x86/core: Add interface to query perfmon_event_map[] directly To: Peter Zijlstra Cc: 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 , David Dunn Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 2, 2022 at 6:43 AM Peter Zijlstra wrote: > Urgh... hate on kvm being a module again. We really need something like > EXPORT_SYMBOL_KVM() or something. Perhaps we should reconsider the current approach of treating the guest as a client of the host perf subsystem via kvm as a proxy. There are several drawbacks to the current approach: 1) If the guest actually sets the counter mask (and invert counter mask) or edge detect in the event selector, we ignore it, because we have no way of requesting that from perf. 2) If a system-wide pinned counter preempts one of kvm's thread-pinned counters, we have no way of letting the guest know, because the architectural specification doesn't allow counters to be suspended. 3) TDX is going to pull the rug out from under us anyway. When the TDX module usurps control of the PMU, any active host counters are going to stop counting. We are going to need a way of telling the host perf subsystem what's happening, or other host perf clients are going to get bogus data. Given what's coming with TDX, I wonder if we should just bite the bullet and cede the PMU to the guest while it's running, even for non-TDX guests. That would solve (1) and (2) as well.