From nobody Wed Jun 17 07:26:44 2026 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0F9103624C4 for ; Thu, 23 Apr 2026 15:03:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776956628; cv=none; b=iL6STvHqNbad68CYETyFAEHm7lLULUAZdBY7/TQvfpH+2qT7deNm7wwMb/hFbTywcYWDiA82wvlpG01uF61BpSW2Om0NWMcdqtY5vdVV4CfgT1m7KlSCzR01KXYqodxBrFy6od0nAvTVIutJehmZdjKZ5o0p4+ZvRkQLiqzi+V0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776956628; c=relaxed/simple; bh=tqL2wS9SOcoEBt8mWJ2tMzb5vBN/09iIE7AsrQkocpg=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=kjMVx3/qlMh/OwDmPr9rKZqwINN54TGhgHgTZHpm0R8Cpy7xcVJ1kgptQ9S7IJohDW2TZEtXh9K0YXE1B02Fpbir1xkc6j0b5dZ/Lo8Bb5+Kj5t27GJbCqsJXWTipCEOhFi4hb7PhthdRbeWHQ6IJYuLUV/5niLvut7+ielSsQo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Tk5KFQLD; arc=none smtp.client-ip=209.85.215.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Tk5KFQLD" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-c7977177675so3455408a12.0 for ; Thu, 23 Apr 2026 08:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1776956625; x=1777561425; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=7CGRZKt5ZrmE9CmVLVQUqmlUNHSwTAQ9ApcqVFaaEIw=; b=Tk5KFQLDyizl0//jrKENXq2be85Iubw4I3aa6A+nbDEcspamFsr/HDSHZ76QCU5waV 1BlVoX6KsL++Nlu+fh2MkMOn/EyMNR3HulskT3jssG8z+dWD9M9T618wSsoY6fkc9AdC Zt4XffcB9sSb/wb4JWJ0GE8Dkt+D/FRwdc5arsde8m3tyFcrCxk99syBFbunzy0/3DsP nqRTAzhfbu20Y3n8P4dVqjMVVtmftR8AVOnaPSdSZ9hsXHoyl4uibghI6Ky+LJMKj3eg QYhlenGyAXAPv5q5UN08zKLodnJeaVriQfMx1zf7RqryQGGbu8cuwryx24X8Pk1JEXqj JGGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776956625; x=1777561425; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7CGRZKt5ZrmE9CmVLVQUqmlUNHSwTAQ9ApcqVFaaEIw=; b=RDDGyBna4sR9dkTn4TIeQdY1xnIefQuz9YD0r2Od9fibVw+1yYFfbhzG40M7fbCZqd vwy8BQkXYxMBQrJRe+RLRewXeRsKS9JL3Pe7y5qFm3OfgkhQU3UKe7DyP3p9HRzxNTfI v0k1EGJDu4dNWrv5V6uyXcKEaN6rDnEBE4faXJcuQAYQjCiEYRPC7eIQf/1tBuH21Ehk WIBl04B2mBBJ2AqpiIicEnQ7SEBIc4aXYQOdRPYhkAdWnLDxo84eDQpfA+8lc9p9569f d0CyVoddHpsWI9cAzXnmWBb1EkRIIR5CBB5AVgcM8ccH2tMuqGC4ecCUnJ7EUuixwsy4 /LBQ== X-Forwarded-Encrypted: i=1; AFNElJ/6+gGPgnzEwG4Nb4szGwyFFJIb9PodMzu6GVEZsMSnPtxSCKLAI66XVCMicThElT1opfVg2LM5PNvOf+s=@vger.kernel.org X-Gm-Message-State: AOJu0YzD5+YMRyvCdWtiKc7++DF8nXDLOV1TRC9D1XKhalIcsDgrub2f C2S4A6zRHiA4P4g4vOUlOHvcWNzOcCoKImUkoRyIoTivSbJ5DkKR6jMPMPn7du9OQN9sDCKY7fl WKUFbtw== X-Received: from pfbll5.prod.google.com ([2002:a05:6a00:7285:b0:82f:9be8:3f2c]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:aa7:88ca:0:b0:82c:d9d0:f482 with SMTP id d2e1a72fcca58-82f8c976ff1mr29068441b3a.46.1776956625063; Thu, 23 Apr 2026 08:03:45 -0700 (PDT) Reply-To: Sean Christopherson Date: Thu, 23 Apr 2026 08:03:37 -0700 In-Reply-To: <20260423150340.463896-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260423150340.463896-1-seanjc@google.com> X-Mailer: git-send-email 2.54.0.545.g6539524ca2-goog Message-ID: <20260423150340.463896-2-seanjc@google.com> Subject: [PATCH v2 1/4] perf/x86/intel: Don't write PEBS_ENABLED on host<=>guest xfers if CPU has isolation From: Sean Christopherson To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, Sean Christopherson , Paolo Bonzini Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Jim Mattson , Mingwei Zhang , Stephane Eranian , Dapeng Mi Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When filling the list of MSRs to be loaded by KVM on VM-Enter and VM-Exit, *never* insert an entry for PEBS_ENABLED if the CPU properly isolates PEBS events, in which case disabling counters via PERF_GLOBAL_CTRL is sufficient to prevent unwanted PEBS events in the guest (or host). Because perf loads PEBS_ENABLE with the unfiltered cpu_hw_events.pebs_enabled, i.e. with both host and guest masks, there is no need to load different values for the guest versus host, perf+KVM can and should simply control which counters are enabled/disabled via PERF_GLOBAL_CTRL. Avoiding touching PEBS_ENABLED fixes a theorized bug where PEBS_ENABLED can end up with "stuck" bits if a PEBS event is throttled better generating the list and actually entering the guest (Intel CPUs can't arbtitrarily block NMIs). And stating the obvious, leaving PEBS_ENABLED as-is avoids three MSR writes on every VMX transition: one each on entry/exit, and one more explicit WRMSR to zero PEBS_ENABLED before VM-Entry (KVM assumes the only reason PEBS_ENABLED is in the load list is if the CPU lacks isolation and thus needs a quiescent period). Fixes: c59a1f106f5c ("KVM: x86/pmu: Add IA32_PEBS_ENABLE MSR emulation for = extended PEBS") Cc: Jim Mattson Cc: Mingwei Zhang Cc: Stephane Eranian Signed-off-by: Sean Christopherson --- arch/x86/events/intel/core.c | 42 ++++++++++++++++++++---------------- 1 file changed, 23 insertions(+), 19 deletions(-) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index 793335c3ce78..002d809f82ef 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -4999,12 +4999,15 @@ static struct perf_guest_switch_msr *intel_guest_ge= t_msrs(int *nr, void *data) struct kvm_pmu *kvm_pmu =3D (struct kvm_pmu *)data; u64 intel_ctrl =3D hybrid(cpuc->pmu, intel_ctrl); u64 pebs_mask =3D cpuc->pebs_enabled & x86_pmu.pebs_capable; - int global_ctrl, pebs_enable; + u64 guest_pebs_mask =3D pebs_mask & ~cpuc->intel_ctrl_host_mask; + int global_ctrl; =20 /* * In addition to obeying exclude_guest/exclude_host, remove bits being * used for PEBS when running a guest, because PEBS writes to virtual - * addresses (not physical addresses). + * addresses (not physical addresses). If the guest wants to utilize + * PEBS, and PEBS can safely enabled in the guest, bits for the guest's + * PEBS-enabled counters will be OR'd back in as appropriate. */ *nr =3D 0; global_ctrl =3D (*nr)++; @@ -5051,24 +5054,25 @@ static struct perf_guest_switch_msr *intel_guest_ge= t_msrs(int *nr, void *data) }; } =20 - pebs_enable =3D (*nr)++; - arr[pebs_enable] =3D (struct perf_guest_switch_msr){ - .msr =3D MSR_IA32_PEBS_ENABLE, - .host =3D cpuc->pebs_enabled & ~cpuc->intel_ctrl_guest_mask, - .guest =3D pebs_mask & ~cpuc->intel_ctrl_host_mask & kvm_pmu->pebs_enabl= e, - }; - - if (arr[pebs_enable].host) { - /* Disable guest PEBS if host PEBS is enabled. */ - arr[pebs_enable].guest =3D 0; - } else { - /* Disable guest PEBS thoroughly for cross-mapped PEBS counters. */ - arr[pebs_enable].guest &=3D ~kvm_pmu->host_cross_mapped_mask; - arr[global_ctrl].guest &=3D ~kvm_pmu->host_cross_mapped_mask; - /* Set hw GLOBAL_CTRL bits for PEBS counter when it runs for guest */ - arr[global_ctrl].guest |=3D arr[pebs_enable].guest; - } + /* + * Disable counters where the guest PMC is different than the host PMC + * being used on behalf of the guest, as the PEBS record includes + * PERF_GLOBAL_STATUS, i.e. the guest will see overflow status for the + * wrong counter(s). Similarly, disallow PEBS in the guest if the host + * is using PEBS, to avoid bleeding host state into PEBS records. + */ + guest_pebs_mask &=3D kvm_pmu->pebs_enable & ~kvm_pmu->host_cross_mapped_m= ask; + if (pebs_mask & ~cpuc->intel_ctrl_guest_mask) + guest_pebs_mask =3D 0; =20 + /* + * Do NOT mess with PEBS_ENABLED. As above, disabling counters via + * PERF_GLOBAL_CTRL is sufficient, and loading a stale PEBS_ENABLED, + * e.g. on VM-Exit, can put the system in a bad state. Simply enable + * counters in PERF_GLOBAL_CTRL, as perf load PEBS_ENABLED with the + * full value, i.e. perf *also* relies on PERF_GLOBAL_CTRL. + */ + arr[global_ctrl].guest |=3D guest_pebs_mask; return arr; } =20 --=20 2.54.0.545.g6539524ca2-goog From nobody Wed Jun 17 07:26:44 2026 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9C46E35DA6C for ; Thu, 23 Apr 2026 15:03:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776956631; cv=none; b=pE8us2NHlY0mVAE9SeSru3r7Gq18LVqdl1LJRaZuzvk1FaKQLmhnqrZ42GG/34sNwI/+oHrpvXnDKX0ZMtJLBIz9TZ/pHO2xSks25jjRY5gtZkKT04GfSqo/zmpvUZIZxZdpTrcVmLUvhUheAV21uGC5Dj0oeIypEHYNeUQkxX0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776956631; c=relaxed/simple; bh=CkcrXIw1Eem4o4QbNMX/btWn5w25geAaYmxE9sQm1Qg=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=S3IS0vpr1J8KNFCn7FcoWJVYOKwMcWf9dC4pt46HKdJ1aY3ZpIKK8r16vEtWhOOer/+7xSCnTGrJYY7wC3FAr9Iq3Shh5jwDPmbXdv3iTtEAr8zlovi+xzX7OmYZYgv3CorwwMZtgA8yDSUn40DrlMcm1xD0hbms/j2beOWMc50= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=iSkf3hxb; arc=none smtp.client-ip=209.85.215.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="iSkf3hxb" Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-c795fa31e18so3404805a12.2 for ; Thu, 23 Apr 2026 08:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1776956630; x=1777561430; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=i2vqUKmveKZlZolMhgpBRxhYsBG7B/PvclnkTlsDmdw=; b=iSkf3hxbMio8zWPrUs0d6Oii4d4M/OBc6e1jxtR0aWJ+jo9yt1eFuxilHcQuKf++fQ NiR+vVWgYl8bDnbbtm5g5yllpZYUaJuRdXaTENH0gPSDijS4h1mM3NR3fI7zjMITrmjZ 87hknsmpaZeuSI7IxGNONRC4rkQWuNxuzci6yBAO+V4w3DiVyQD51szwEfClKpJi0LNe jPBcK+rNGswiGFC/SA4hIMXJPVE1tsgFlut+TyFHZsU97mdhMA4044Q+NGUvs8yt+kBZ YyLt3kkvGHX92bemSTLqU4qdtnVf8dE4pET3gpmyACNIIq6KUXeGJ2F0yi8IlaLgM25d fHXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776956630; x=1777561430; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=i2vqUKmveKZlZolMhgpBRxhYsBG7B/PvclnkTlsDmdw=; b=GzA1KmeGCacbhiaOr03sZyRgfCDblkh1no6GLU/xSgVC95kDxQHEPTzxz7c5aVm4Es TDoeq1/i9iJ3JYJfAG26t/b81IF2jREeWPDcERApMYawQ9emQcIp0cSqGILu9fAR7Vjk wtP3K82uJsfo0cS9M/GkVGgwGNC9usLmuqZKHeE/dayeeCooCZniFrH6SSTitGyN8BWm /O+ca8U9kmn07vdNXiuLqfTtMXj3yjsuGdMy/HwaXCg1sDMCHyQk9YLIMk1EaVrG+Eg/ 6Kh3UhV6fOdr0RQU9f9RNsTAeNyxRE8QKc68oXXvHbd8vOmvGCXETfGeK/o/kcBXrLpT 2qGQ== X-Forwarded-Encrypted: i=1; AFNElJ+V6WqgSSR09nPGjgcERnTXTHcg3r7ovDnq+kDOkCw+liapww+08vyO6jLQ3f7RM9SbpdCbWH9f57Mj/s8=@vger.kernel.org X-Gm-Message-State: AOJu0YxoUOjqyFI0iUid+ZkP1BpOOTYrbVg8GIPyAfxVqQh4PkI3yRqe 3ElWfzexbll7ocBYCM4ujf4lZXW70/d3HWfpy4977wGPJSqnQ02+nQRFukfQig1OVNvgKnjKXr7 GE61xtQ== X-Received: from pgnp16.prod.google.com ([2002:a63:7f50:0:b0:c79:66d7:2ed5]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:7285:b0:39b:e321:67ea with SMTP id adf61e73a8af0-3a08d8fba25mr30645370637.45.1776956627069; Thu, 23 Apr 2026 08:03:47 -0700 (PDT) Reply-To: Sean Christopherson Date: Thu, 23 Apr 2026 08:03:38 -0700 In-Reply-To: <20260423150340.463896-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260423150340.463896-1-seanjc@google.com> X-Mailer: git-send-email 2.54.0.545.g6539524ca2-goog Message-ID: <20260423150340.463896-3-seanjc@google.com> Subject: [PATCH v2 2/4] perf/x86/intel: Don't context switch DS_AREA (and PEBS config) if PEBS is unused From: Sean Christopherson To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, Sean Christopherson , Paolo Bonzini Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Jim Mattson , Mingwei Zhang , Stephane Eranian , Dapeng Mi Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When filling the list of MSRs to be loaded by KVM on VM-Enter and VM-Exit, load the guest values for DS_AREA and (conditionally) MSR_PEBS_DATA_CFG if and only if PEBS will be active in the guest, i.e. only if a PEBS record may be generated while running the guest. As shown by the !pebs_ept path, it's perfectly safe to run with the host's DS_AREA, so long as PEBS-enabled counters are disabled via PERF_GLOBAL_CTRL. Omitting DS_AREA and MSR_PEBS_DATA_CFG when PEBS is unused saves two MSR writes per MSR on each VMX transition, i.e. eliminates two/four pointless MSR writes on each VMX roundtrip when PEBS isn't being used by the guest. Fixes: c59a1f106f5c ("KVM: x86/pmu: Add IA32_PEBS_ENABLE MSR emulation for = extended PEBS") Cc: Jim Mattson Cc: Mingwei Zhang Cc: Stephane Eranian Reviewed-by: Jim Mattson Signed-off-by: Sean Christopherson Reviewed-by: Dapeng Mi --- arch/x86/events/intel/core.c | 39 +++++++++++++++++++++++------------- 1 file changed, 25 insertions(+), 14 deletions(-) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index 002d809f82ef..407fd392fd46 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -5037,23 +5037,14 @@ static struct perf_guest_switch_msr *intel_guest_ge= t_msrs(int *nr, void *data) return arr; } =20 + /* + * If the guest won't use PEBS or the CPU doesn't support PEBS in the + * guest, then there's nothing more to do as disabling PMCs via + * PERF_GLOBAL_CTRL is sufficient on CPUs with guest/host isolation. + */ if (!kvm_pmu || !x86_pmu.pebs_ept) return arr; =20 - arr[(*nr)++] =3D (struct perf_guest_switch_msr){ - .msr =3D MSR_IA32_DS_AREA, - .host =3D (unsigned long)cpuc->ds, - .guest =3D kvm_pmu->ds_area, - }; - - if (x86_pmu.intel_cap.pebs_baseline) { - arr[(*nr)++] =3D (struct perf_guest_switch_msr){ - .msr =3D MSR_PEBS_DATA_CFG, - .host =3D cpuc->active_pebs_data_cfg, - .guest =3D kvm_pmu->pebs_data_cfg, - }; - } - /* * Disable counters where the guest PMC is different than the host PMC * being used on behalf of the guest, as the PEBS record includes @@ -5065,6 +5056,26 @@ static struct perf_guest_switch_msr *intel_guest_get= _msrs(int *nr, void *data) if (pebs_mask & ~cpuc->intel_ctrl_guest_mask) guest_pebs_mask =3D 0; =20 + /* + * Context switch DS_AREA and PEBS_DATA_CFG if and only if PEBS will be + * active in the guest; if no records will be generated while the guest + * is running, then simply keep the host values resident in hardware. + */ + arr[(*nr)++] =3D (struct perf_guest_switch_msr){ + .msr =3D MSR_IA32_DS_AREA, + .host =3D (unsigned long)cpuc->ds, + .guest =3D guest_pebs_mask ? kvm_pmu->ds_area : (unsigned long)cpuc->ds, + }; + + if (x86_pmu.intel_cap.pebs_baseline) { + arr[(*nr)++] =3D (struct perf_guest_switch_msr){ + .msr =3D MSR_PEBS_DATA_CFG, + .host =3D cpuc->active_pebs_data_cfg, + .guest =3D guest_pebs_mask ? kvm_pmu->pebs_data_cfg : + cpuc->active_pebs_data_cfg, + }; + } + /* * Do NOT mess with PEBS_ENABLED. As above, disabling counters via * PERF_GLOBAL_CTRL is sufficient, and loading a stale PEBS_ENABLED, --=20 2.54.0.545.g6539524ca2-goog From nobody Wed Jun 17 07:26:44 2026 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 500AB368977 for ; Thu, 23 Apr 2026 15:03:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776956632; cv=none; b=uYfNgh8FQ+lg5bF9adRBPeBATin4g5xFeapiNh3SnGRqyjncEqI1cnfm2OrDDfb395hMKcihNkkXTYG+b/Sg7lxda7gpSNqzSBcUNybCeS2EcctPSAUCpWC9zmgp7itNZUXq2usBuSSUUtoHbWP2LmhrQJB0DB8TMKBVs6CUf4o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776956632; c=relaxed/simple; bh=Qq+a1DlHnsbnGt0qwZoOkE6eAMMyZT69FHNC3qdZqpA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=HjQ/tJN4ElkwvMN88S/1dyIjztmUDLnB7a2EJSB78/UnD3zdObNBaaYrpmuSYexRHQUK35j7SVCUWfwpRutA1A8HtXv8146YT2iM9MGbmDxxW1dNx4O0dnvZUhirEV9lGaxskp6QMpVgfhev3KEpwJFb0hiSSUjgBd+3ftxeFgY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=YuZZs/B1; arc=none smtp.client-ip=209.85.216.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="YuZZs/B1" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-35d9e67f6dcso6404594a91.1 for ; Thu, 23 Apr 2026 08:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1776956630; x=1777561430; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=Aj9Le9dSw7rMaT45LUpduHxRBjTdQmy+Rvmt2ooyxYY=; b=YuZZs/B1kl28xdh7IROcrI5qPNfRCKiTanK5eSe71mgY1tRaw/DSUsM3TB9d3zT3Sp XXs3+xBoh1PCXxEloBAdeRDMGQB2yEKrUnRud0fiSaTp7w6cVWuflGrxkfrLE6yA4CM5 rVKlJar0pPbT/NWdWx8sw+QCltfSLnTmg+YdDFytzqWhTmjXxz2oVLWojk5hXvNYUTZ0 CBf14XpJ3rnfphIC5iW6+E9+3Ymv7NPWr91F7LJKLqYgcsoCVP9x/oVQ8dphQnp22AbC /5qPP9sNobAqbUrOkKvNMKYIythBGA8gyAQdZ47DTB+u6H1vmJLf3bhHQmp/NoViRrv6 IAWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776956630; x=1777561430; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Aj9Le9dSw7rMaT45LUpduHxRBjTdQmy+Rvmt2ooyxYY=; b=JohGqQYaTsqOwOqRgmUGdhrzZ8jz7yluWpaNEkdZnNfewWHozeLE90XI8niMyDS3KF CCk66b4tPZ/cggGsGnxyKM5PlUYYgQoArKjq0g5YfB4tDrZnOGU4CuC9sGOftykS5oRQ 0ZtXozofytUUokHnONosPN6XUAzKnPnTj4WxJLB7CU3o0Sj0zYSDAZYSbGSiHRqe4c/O 8YkHNrXBQEaduyOY+dDi3ThfPsKoeu5/bLEOVd+r5SLjxuRUT/Pc0HKdukYE+5njVrNm GPk+4JOZtdm3lUoj7VB/U9rhSnwIZWmnzVD+/nlBCvg9UG5V8yJC9ghXf6cLVKKOpa1l zR7A== X-Forwarded-Encrypted: i=1; AFNElJ/IxYWMKZQ2nZ9WpbLJ9eO46p69aMd2xKRyYnHsox3wAoqRHoRI1ZUAko7GBQ5Y3syA4WwPRYomLOK3rcY=@vger.kernel.org X-Gm-Message-State: AOJu0YwZZQItUrtbVfWfMQvK0GRH3BrYg2RMk7lHPi3CqTmAIX8QVGEf 0wRanNLtH8jSCwoclkYCbYsSqQa/TnbddjQMZKD33g677ixrKEiler3XKhwmTdx9JjTrwCbXZRy xg1BCgA== X-Received: from pfbho17.prod.google.com ([2002:a05:6a00:8811:b0:82f:7833:9aa9]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:9996:b0:39b:bee4:2952 with SMTP id adf61e73a8af0-3a08d908020mr32339418637.45.1776956629325; Thu, 23 Apr 2026 08:03:49 -0700 (PDT) Reply-To: Sean Christopherson Date: Thu, 23 Apr 2026 08:03:39 -0700 In-Reply-To: <20260423150340.463896-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260423150340.463896-1-seanjc@google.com> X-Mailer: git-send-email 2.54.0.545.g6539524ca2-goog Message-ID: <20260423150340.463896-4-seanjc@google.com> Subject: [PATCH v2 3/4] perf/x86/intel: Make @data a mandatory param for intel_guest_get_msrs() From: Sean Christopherson To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, Sean Christopherson , Paolo Bonzini Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Jim Mattson , Mingwei Zhang , Stephane Eranian , Dapeng Mi Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Drop "support" for passing a NULL @data/@kvm_pmu param when getting guest MSRs. KVM, the only in-tree user, unconditionally passes a non-NULL pointer, and carrying code that suggests @data may be NULL is confusing, e.g. incorrectly implies that there are scenarios where KVM doesn't pass a PMU context. Fixes: 8183a538cd95 ("KVM: x86/pmu: Add IA32_DS_AREA MSR emulation to suppo= rt guest DS") Cc: Jim Mattson Cc: Mingwei Zhang Cc: Stephane Eranian Reviewed-by: Jim Mattson Signed-off-by: Sean Christopherson Reviewed-by: Dapeng Mi --- arch/x86/events/intel/core.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index 407fd392fd46..7403ca721b6a 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -5038,11 +5038,11 @@ static struct perf_guest_switch_msr *intel_guest_ge= t_msrs(int *nr, void *data) } =20 /* - * If the guest won't use PEBS or the CPU doesn't support PEBS in the - * guest, then there's nothing more to do as disabling PMCs via - * PERF_GLOBAL_CTRL is sufficient on CPUs with guest/host isolation. + * If the CPU doesn't support PEBS in the guest, then there's nothing + * more to do as disabling PMCs via PERF_GLOBAL_CTRL is sufficient on + * CPUs with guest/host isolation. */ - if (!kvm_pmu || !x86_pmu.pebs_ept) + if (!x86_pmu.pebs_ept) return arr; =20 /* --=20 2.54.0.545.g6539524ca2-goog From nobody Wed Jun 17 07:26:44 2026 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5EDD336A022 for ; Thu, 23 Apr 2026 15:03:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776956635; cv=none; b=DZtO1h3FVgU9M9yOSzC2CDuezxsYeJBNvt1jwP7IAudHPnu5P2LdXBqU2WNdVoFpO9LDjZLm3wqxjKoPaRCNePLy1JbDoqtbsUZp8crR7OaGuolAsQaPRUYpabwh8pX+BbpQoCZn99Zd7Tcmqfyve31xOvHGwZQChEdl8DIURPc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776956635; c=relaxed/simple; bh=jpQO1WdQewDJJD+/2lHriLZqD7e0aq+INMWe8jDdu20=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=UpOJB7ax7gtYehFytiv5pycp/c6h8jbsDUOtraU8e+fGvtACNNjpPz5YcULtngu2AKGZczpJYFtvUqE8qX/jiowJhul2VrBw4Kh/5iVAa4iuaNX8P1A5rErsWVY2TNa/EnG+qE4H1zv5LjpfMCWDJC7j0TUrA3SJJKspEixsNVs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=feRQmxuB; arc=none smtp.client-ip=209.85.215.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="feRQmxuB" Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-c70ea91bfe1so3347338a12.1 for ; Thu, 23 Apr 2026 08:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1776956632; x=1777561432; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=g4hqZqzA29fiSYvwhALKz/X4F2wrJSkQyuh0PCbKMfE=; b=feRQmxuBT2KDAyAM9JngXKXwwI/gQvVp9LGL2cOa0bvNBu86NzxrfPpCAcxvbG3UNX pF4R1lw1KryA35DOwzJdglnyovMIdEBWRxks4ldUgj8hn8ywpYtoosTf8Q/sQdw68aLA 0+/XJOdIi9fN8yrJpsxpUh8e2ZRVHOgIJO4vcAUq2NsZ9bdfimuDBJFJ+Gzir4kWm4lL V0WLn50Vg2r+YSJwi/1t/21V7VcX2S9ofstIh/zm6lZbQEyJb3GsyWUBYyTmBlexrGCk uH+xYKpnaJekJP53k8jFbBXvzwD3p4XIDCdCLKQZo1Yx6lzeK4d6dIU71L4DfejBznVu rrEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776956632; x=1777561432; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=g4hqZqzA29fiSYvwhALKz/X4F2wrJSkQyuh0PCbKMfE=; b=FR0zdv+Wv4/NDrTZJei0Aj4vJlekV9G22bHA/4EkYs4ISgl15YxbQduDea0KfR9BP3 vHvwCYOy2njzwCTn4sikp6LjNUKl4aLd5k7Gty186v5ew2D4/2bai5LUOXLWMW8j1X9b 8YvUC602forp4GvnXu/JnlYDVp34SgF7RCytMMfU7fhDf+gGMF+56SKxEXlw5wysP4uO lL370bQXXPz8QQM2xbUmcQthyV35T7vxYPV6ZPxUp+14ikV//U/uiKW9B/fc03T3EBtt n2pWHjmdhgp5sHfBxQczo7lAgtQTLj1ZHuATctP8d+zV9cB7d1M+/egrmdPbGfIXPhq9 bGvA== X-Forwarded-Encrypted: i=1; AFNElJ/ABDAvb0uOWeMLdaRQBaikGquUBzlb0ypzr57gSMDqhS54pzcNl5tpLtaCBFbiDpNLze7Qa+9DoQ7vdiU=@vger.kernel.org X-Gm-Message-State: AOJu0YweTOdsNLmMCxKncn4uotjAu1oGHxKCOcIXW4uV9LoKLwfhceHp xRHU2ar4VVBMcDEYw2hm2CNmKIsuhEp2oeR8znfUCixFiodh9cNrOg04O2CDJz6/eka/D8VsyXR MhB1m/A== X-Received: from pgct19.prod.google.com ([2002:a05:6a02:5293:b0:c79:65ab:b3b4]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:a113:b0:398:7855:1596 with SMTP id adf61e73a8af0-3a08d6876a7mr29711555637.10.1776956631436; Thu, 23 Apr 2026 08:03:51 -0700 (PDT) Reply-To: Sean Christopherson Date: Thu, 23 Apr 2026 08:03:40 -0700 In-Reply-To: <20260423150340.463896-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260423150340.463896-1-seanjc@google.com> X-Mailer: git-send-email 2.54.0.545.g6539524ca2-goog Message-ID: <20260423150340.463896-5-seanjc@google.com> Subject: [PATCH v2 4/4] perf/x86: KVM: Have perf define a dedicated struct for getting guest PEBS data From: Sean Christopherson To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, Sean Christopherson , Paolo Bonzini Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Jim Mattson , Mingwei Zhang , Stephane Eranian , Dapeng Mi Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Have perf define a struct for getting guest PEBS data from KVM instead of poking into the kvm_pmu structure. Passing in an entire "struct kvm_pmu" _as an opaque pointer_ to get at four fields is silly, especially since one of the fields exists purely to convey information to perf, i.e. isn't used by KVM. Perf should also own its APIs, i.e. define what fields/data it needs, not rely on KVM to throw fields into data structures that effectively hold KVM-internal state. Opportunistically rephrase the comment about cross-mapped counters to explain *why* PEBS needs to be disabled. Reviewed-by: Dapeng Mi Signed-off-by: Sean Christopherson Reviewed-by: Jim Mattson --- arch/x86/events/core.c | 5 +++-- arch/x86/events/intel/core.c | 14 +++++++------- arch/x86/events/perf_event.h | 3 ++- arch/x86/include/asm/kvm_host.h | 9 --------- arch/x86/include/asm/perf_event.h | 12 ++++++++++-- arch/x86/kvm/vmx/pmu_intel.c | 20 +++++++++++++++++--- arch/x86/kvm/vmx/vmx.c | 11 +++++++---- arch/x86/kvm/vmx/vmx.h | 2 +- 8 files changed, 47 insertions(+), 29 deletions(-) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 810ab21ffd99..e6f788e72e72 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -723,9 +723,10 @@ void x86_pmu_disable_all(void) } } =20 -struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr, void *data) +struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr, + struct x86_guest_pebs *guest_pebs) { - return static_call(x86_pmu_guest_get_msrs)(nr, data); + return static_call(x86_pmu_guest_get_msrs)(nr, guest_pebs); } EXPORT_SYMBOL_FOR_KVM(perf_guest_get_msrs); =20 diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index 7403ca721b6a..04d9c51335d7 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -14,7 +14,6 @@ #include #include #include -#include =20 #include #include @@ -4992,11 +4991,11 @@ static int intel_pmu_hw_config(struct perf_event *e= vent) * when it uses {RD,WR}MSR, which should be handled by the KVM context, * specifically in the intel_pmu_{get,set}_msr(). */ -static struct perf_guest_switch_msr *intel_guest_get_msrs(int *nr, void *d= ata) +static struct perf_guest_switch_msr *intel_guest_get_msrs(int *nr, + struct x86_guest_pebs *guest_pebs) { struct cpu_hw_events *cpuc =3D this_cpu_ptr(&cpu_hw_events); struct perf_guest_switch_msr *arr =3D cpuc->guest_switch_msrs; - struct kvm_pmu *kvm_pmu =3D (struct kvm_pmu *)data; u64 intel_ctrl =3D hybrid(cpuc->pmu, intel_ctrl); u64 pebs_mask =3D cpuc->pebs_enabled & x86_pmu.pebs_capable; u64 guest_pebs_mask =3D pebs_mask & ~cpuc->intel_ctrl_host_mask; @@ -5052,7 +5051,7 @@ static struct perf_guest_switch_msr *intel_guest_get_= msrs(int *nr, void *data) * wrong counter(s). Similarly, disallow PEBS in the guest if the host * is using PEBS, to avoid bleeding host state into PEBS records. */ - guest_pebs_mask &=3D kvm_pmu->pebs_enable & ~kvm_pmu->host_cross_mapped_m= ask; + guest_pebs_mask &=3D guest_pebs->enable & ~guest_pebs->cross_mapped_mask; if (pebs_mask & ~cpuc->intel_ctrl_guest_mask) guest_pebs_mask =3D 0; =20 @@ -5064,14 +5063,14 @@ static struct perf_guest_switch_msr *intel_guest_ge= t_msrs(int *nr, void *data) arr[(*nr)++] =3D (struct perf_guest_switch_msr){ .msr =3D MSR_IA32_DS_AREA, .host =3D (unsigned long)cpuc->ds, - .guest =3D guest_pebs_mask ? kvm_pmu->ds_area : (unsigned long)cpuc->ds, + .guest =3D guest_pebs_mask ? guest_pebs->ds_area : (unsigned long)cpuc->= ds, }; =20 if (x86_pmu.intel_cap.pebs_baseline) { arr[(*nr)++] =3D (struct perf_guest_switch_msr){ .msr =3D MSR_PEBS_DATA_CFG, .host =3D cpuc->active_pebs_data_cfg, - .guest =3D guest_pebs_mask ? kvm_pmu->pebs_data_cfg : + .guest =3D guest_pebs_mask ? guest_pebs->data_cfg : cpuc->active_pebs_data_cfg, }; } @@ -5087,7 +5086,8 @@ static struct perf_guest_switch_msr *intel_guest_get_= msrs(int *nr, void *data) return arr; } =20 -static struct perf_guest_switch_msr *core_guest_get_msrs(int *nr, void *da= ta) +static struct perf_guest_switch_msr *core_guest_get_msrs(int *nr, + struct x86_guest_pebs *guest_pebs) { struct cpu_hw_events *cpuc =3D this_cpu_ptr(&cpu_hw_events); struct perf_guest_switch_msr *arr =3D cpuc->guest_switch_msrs; diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h index fad87d3c8b2c..19d811ca6b05 100644 --- a/arch/x86/events/perf_event.h +++ b/arch/x86/events/perf_event.h @@ -1023,7 +1023,8 @@ struct x86_pmu { /* * Intel host/guest support (KVM) */ - struct perf_guest_switch_msr *(*guest_get_msrs)(int *nr, void *data); + struct perf_guest_switch_msr *(*guest_get_msrs)(int *nr, + struct x86_guest_pebs *guest_pebs); =20 /* * Check period value for PERF_EVENT_IOC_PERIOD ioctl. diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_hos= t.h index c470e40a00aa..91b070168947 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -600,15 +600,6 @@ struct kvm_pmu { u64 pebs_data_cfg; u64 pebs_data_cfg_rsvd; =20 - /* - * If a guest counter is cross-mapped to host counter with different - * index, its PEBS capability will be temporarily disabled. - * - * The user should make sure that this mask is updated - * after disabling interrupts and before perf_guest_get_msrs(); - */ - u64 host_cross_mapped_mask; - /* * The gate to release perf_events not marked in * pmc_in_use only once in a vcpu time slice. diff --git a/arch/x86/include/asm/perf_event.h b/arch/x86/include/asm/perf_= event.h index ff5acb8b199b..5340d8bb1d92 100644 --- a/arch/x86/include/asm/perf_event.h +++ b/arch/x86/include/asm/perf_event.h @@ -769,11 +769,19 @@ extern void perf_load_guest_lvtpc(u32 guest_lvtpc); extern void perf_put_guest_lvtpc(void); #endif =20 +struct x86_guest_pebs { + u64 enable; + u64 ds_area; + u64 data_cfg; + u64 cross_mapped_mask; +}; #if defined(CONFIG_PERF_EVENTS) && defined(CONFIG_CPU_SUP_INTEL) -extern struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr, void *da= ta); +extern struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr, + struct x86_guest_pebs *guest_pebs); extern void x86_perf_get_lbr(struct x86_pmu_lbr *lbr); #else -struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr, void *data); +struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr, + struct x86_guest_pebs *guest_pebs); static inline void x86_perf_get_lbr(struct x86_pmu_lbr *lbr) { memset(lbr, 0, sizeof(*lbr)); diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c index 27eb76e6b6a0..0197007593f3 100644 --- a/arch/x86/kvm/vmx/pmu_intel.c +++ b/arch/x86/kvm/vmx/pmu_intel.c @@ -736,11 +736,24 @@ static void intel_pmu_cleanup(struct kvm_vcpu *vcpu) intel_pmu_release_guest_lbr_event(vcpu); } =20 -void intel_pmu_cross_mapped_check(struct kvm_pmu *pmu) +u64 intel_pmu_get_cross_mapped_mask(struct kvm_pmu *pmu) { - struct kvm_pmc *pmc =3D NULL; + u64 host_cross_mapped_mask; + struct kvm_pmc *pmc; int bit, hw_idx; =20 + if (!(pmu->pebs_enable & pmu->global_ctrl)) + return 0; + + /* + * Provide a mask of counters that are cross-mapped between the guest + * and the host, i.e. where a guest PMC is mapped to a host PMC with a + * different index. PEBS records hold a PERF_GLOBAL_STATUS snapshot, + * and so PEBS-enabled counters need to hold the correct index so as + * not to confuse the guest. + */ + host_cross_mapped_mask =3D 0; + kvm_for_each_pmc(pmu, pmc, bit, (unsigned long *)&pmu->global_ctrl) { if (!pmc_is_locally_enabled(pmc) || !pmc_is_globally_enabled(pmc) || !pmc->perf_event) @@ -752,8 +765,9 @@ void intel_pmu_cross_mapped_check(struct kvm_pmu *pmu) */ hw_idx =3D pmc->perf_event->hw.idx; if (hw_idx !=3D pmc->idx && hw_idx > -1) - pmu->host_cross_mapped_mask |=3D BIT_ULL(hw_idx); + host_cross_mapped_mask |=3D BIT_ULL(hw_idx); } + return host_cross_mapped_mask; } =20 static bool intel_pmu_is_mediated_pmu_supported(struct x86_pmu_capability = *host_pmu) diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index a29896a9ef14..e6c1c64a8c94 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -7313,12 +7313,15 @@ static void atomic_switch_perf_msrs(struct vcpu_vmx= *vmx) if (kvm_vcpu_has_mediated_pmu(&vmx->vcpu)) return; =20 - pmu->host_cross_mapped_mask =3D 0; - if (pmu->pebs_enable & pmu->global_ctrl) - intel_pmu_cross_mapped_check(pmu); + struct x86_guest_pebs guest_pebs =3D { + .enable =3D pmu->pebs_enable, + .ds_area =3D pmu->ds_area, + .data_cfg =3D pmu->pebs_data_cfg, + .cross_mapped_mask =3D intel_pmu_get_cross_mapped_mask(pmu), + }; =20 /* Note, nr_msrs may be garbage if perf_guest_get_msrs() returns NULL. */ - msrs =3D perf_guest_get_msrs(&nr_msrs, (void *)pmu); + msrs =3D perf_guest_get_msrs(&nr_msrs, &guest_pebs); if (!msrs) return; =20 diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h index db84e8001da5..0c4563472940 100644 --- a/arch/x86/kvm/vmx/vmx.h +++ b/arch/x86/kvm/vmx/vmx.h @@ -659,7 +659,7 @@ static __always_inline struct vcpu_vmx *to_vmx(struct k= vm_vcpu *vcpu) return container_of(vcpu, struct vcpu_vmx, vcpu); } =20 -void intel_pmu_cross_mapped_check(struct kvm_pmu *pmu); +u64 intel_pmu_get_cross_mapped_mask(struct kvm_pmu *pmu); int intel_pmu_create_guest_lbr_event(struct kvm_vcpu *vcpu); void vmx_passthrough_lbr_msrs(struct kvm_vcpu *vcpu); =20 --=20 2.54.0.545.g6539524ca2-goog