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 F0B2CC001DC for ; Wed, 12 Jul 2023 16:12:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232012AbjGLQM3 (ORCPT ); Wed, 12 Jul 2023 12:12:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46674 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231773AbjGLQM0 (ORCPT ); Wed, 12 Jul 2023 12:12:26 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F37881BF6 for ; Wed, 12 Jul 2023 09:11:55 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-c64521ac8d6so7069441276.1 for ; Wed, 12 Jul 2023 09:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689178302; x=1691770302; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=jUTKveXRPyLPHLkVKvmFTziE4B+NDus/75xf0DkHGe0=; b=LXQXMaFMV7pPyOMePG4Vf89vY4jUnQXjuSq2D27W5tED/0cZpSK/S5xod8YmliJe8i 4YihG5B1pEKqxQeQfyWLBovG1Ov71fagz0sok8Ng+h7DXqVEexClbCd+HVrFHsiCwEyJ ApWw3btGejBn8ymD4TUY1sXer4CRs1jp936OfV82x/jXM9NexwTarEZ4TEJv7ngMbRyP i6rS3K2mVGrv0Ge6c+Z3UztxgJ+7t64OmQ+2aFsif76IO9T7MsCnQSQvqRZqzyo4ffbK 5F7NMTu22lQPV+eqB1O5IXO7XGGIhMFcXd9IPdfqiRxmNbdVG4KwrZcqQbicRlmU1RL+ InpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689178302; x=1691770302; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jUTKveXRPyLPHLkVKvmFTziE4B+NDus/75xf0DkHGe0=; b=JUMc6oc0xDzS9hRwU913ztcuRgLqvEm0G4ydPAjJ8LLwvq0eXpDRrx76kJ43ZXFu94 DLGEcOYW4KTrRVdF/dUSqbzAUbjHgCGgMv6j+U9OsgPtb7NFgsRk5ie3VK4E7gU/iwxB MGEB+Y3Fzd01XEBl//t465dKiFAoQtyEFNbPYLgnlIYpFN9bTGZj45aVf1kQrRtQ15pG jXP1xfj5atsxr97Cn5cB+J4GWQubhXKU7boyOBv9trSUoGUqCZUxCWT6tunjZs25JNAL mtG459zgHuOHjyrG7fhqH5I/5iWzwqfW0kmWcvtVDyyMd+KNVjy3OjJbRpBvunNodbaq oA+Q== X-Gm-Message-State: ABy/qLazj+x4/FMU4JxtxRONiS0nhIPxKVsL5FXP/mS6Sh7iLCe7ecDu fLIMur+N7usqr/Mhp5/sRuIn8kAoad4= X-Google-Smtp-Source: APBJJlFVcvLQkVS45NrzBmJkFvBrCw7Xlwqb87hH0td+AdvTOe3wWR2jdpyyygwxI2MOPFdnkRZWvaIrTS8= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:ccc2:0:b0:c41:4696:e879 with SMTP id l185-20020a25ccc2000000b00c414696e879mr165043ybf.7.1689178302438; Wed, 12 Jul 2023 09:11:42 -0700 (PDT) Date: Wed, 12 Jul 2023 09:11:40 -0700 In-Reply-To: <81c32ae2-ff21-131f-e498-f87b1e7fe3b5@gmail.com> Mime-Version: 1.0 References: <20230607010206.1425277-1-seanjc@google.com> <20230607010206.1425277-5-seanjc@google.com> <81c32ae2-ff21-131f-e498-f87b1e7fe3b5@gmail.com> Message-ID: Subject: Re: [PATCH 4/4] KVM: x86/pmu: Move .hw_event_available() check out of PMC filter helper From: Sean Christopherson To: Like Xu Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Aaron Lewis , Paolo Bonzini Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 12, 2023, Like Xu wrote: > On 2023/6/7 09:02, Sean Christopherson wrote: > > Move the call to kvm_x86_pmu.hw_event_available(), which has nothing to > > with the userspace PMU filter, out of check_pmu_event_filter() and into > > its sole caller pmc_event_is_allowed(). pmc_event_is_allowed() didn't > > exist when commit 7aadaa988c5e ("KVM: x86/pmu: Drop amd_event_mapping[] > > in the KVM context"), so presumably the motivation for invoking > > .hw_event_available() from check_pmu_event_filter() was to avoid having > > to add multiple call sites. > > The event unavailability check based on intel cpuid is, in my opinion, > part of our pmu_event_filter mechanism. Unavailable events can be > defined either by KVM userspace or by architectural cpuid (if any). > > The bigger issue here is what happens when the two rules conflict, and > the answer can be found more easily by putting the two parts in one > function (the architectural cpuid rule takes precedence). I want to clearly differentiate between what KVM allows and what userspace allows, and specifically I want to use "filter" only to describe userspace intervention as much as possible. Outside of kvm_get_filtered_xcr0(), which I would classify as userspace-defined behavior (albeit rather indirectly), and a few architecturally defined "filter" terms from Intel and AMD, we don't use "filter" in KVM to describe KVM behavior. IMO, there's a lot of value in being able to associate "filter" with userspace desires, e.g. just mentioning "filtering" immediately frames a conversation as dealing with userspace's wants, not internal KVM behavior.