From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (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 60123135A53 for ; Wed, 14 May 2025 23:30:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747265456; cv=none; b=KJiNViq2qGyU1eBF0V35pY1Bwrh0F5gU4vJuNdf69BJNtsaDqZXJT7KUDry3pxt/Pqbf62rK6L/HfJApTLtGlQrjZPTQZVqkhN2N8dN3hZktdyjQ7bA/EEOXO9plMmqfROiZRDn+BzoogX/yclybX5yBED/LcTUX5ZKVOSMMduA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747265456; c=relaxed/simple; bh=8IwAmJ0usLb0XmLJEmRAj1KQT7kUoSHh+GUD4ztFINU=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=VvCQuRuQTe3exFWNNr/a5vmihXv3X8BDR8uFkM+3kBguSvNafIdplI6kMvYYt0sO8rJ5PO5MD8VBxtpT02m1kwjaeYVUctn+HKv3WuY8vt6K750IFvHezO+nWD5u9juP/RIKGGrr863R1Lh7xV9z9kDaPH8yTGZjtmtDHbzYTxs= 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=rhS8+rB6; arc=none smtp.client-ip=209.85.216.74 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="rhS8+rB6" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-30c4bdd0618so333912a91.1 for ; Wed, 14 May 2025 16:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1747265453; x=1747870253; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=K4/upwCU1p7ZhRZCIWHVB5zuv5a/gxQLx/KwiZLDsIs=; b=rhS8+rB6n5ez4I56fUlA2ea8yo2iMu8mHM4munJorrMkjZ4JK0fe6kOQpePclO/gRM LE8FWui0h6m8RKwc0n7dHRFM/H/lL5x+7xRFg6ALmnIL6k+oyWoGM3xGoB4MxX6ps6vS fM7R1ORHSZquSl8kYImaTs+VcCvSgf+IbOihdLZbZLxsat3vfEZBKkvjUfL2ZYCcXKdx 9Q/jGgOLe3dEHLhW6D4TyNAsOofvZsbo7nKVs667kRgenKkZxkYqHIyHgc4kzRRGvfm3 R+tpC7hEnI84pJufBOZtD9rb6+uiwieEEmV3SLGvNE/jrKCQbMpxKDCNZ02bEMRhAZwo Edaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747265453; x=1747870253; 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=K4/upwCU1p7ZhRZCIWHVB5zuv5a/gxQLx/KwiZLDsIs=; b=DxpTN5BMkcZKPlw31dJRe21FOT4NkXtO4KELx5JKYkBM9VTSTTv1irCrkV1jsr/WzC DLTMmS9BgYuUQIdjTEt2XFzeKGayvroGKBo5jlc62FKL/YkXDNyK3GUQo9w6weV24XMI uzA5d0OqWzcaod9YY0C0tANsdJhMI8GqTxGBjdxi8FtmOVOd2bS572PusrXploRmp3CR sKoYDgHpRTL3KnDnQsHC7LROmIRqoaOVMkc+YdUOctTJ6C4GHaD9cRtiHZ4czbEpUpsz //pbA966lgiLaZa0OMZOIgmSzmk+4IGfIzxi88A+VtgdTEZWjQiX0fuoUvC5dK3uzCFw zrow== X-Forwarded-Encrypted: i=1; AJvYcCV13Ii3Q3J7MU8+YGNrBaDxEDIs+ZNfPPX6miIS9fy5PQOK3PizcvPE4PGRgpzodwIwlt9LLZLIAt8Czlsu1lIr@vger.kernel.org X-Gm-Message-State: AOJu0YwW5HUr1nI5XkM/gn8l4fjyDZMtPJOQ5KewSBxLhat+87fdyDGZ Q+do34rh5cbE4oSh3aEsHSL9BkppHNsVIZPwLbmni5stVcld/yqJn4IxFmCz73nvF1K9pLx7vv+ aXg== X-Google-Smtp-Source: AGHT+IFAtfFAcg5G+bktrxdFp1CjONIgOLPqtbYX0j8nNBPhJiLTtnFl1U1b1LHV+tCsNxvNYjV//Y0pDCQ= X-Received: from pjbee14.prod.google.com ([2002:a17:90a:fc4e:b0:301:1bf5:2f07]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:5292:b0:2ff:5357:1c7f with SMTP id 98e67ed59e1d1-30e2e64260bmr8268883a91.30.1747265453399; Wed, 14 May 2025 16:30:53 -0700 (PDT) Date: Wed, 14 May 2025 16:30:51 -0700 In-Reply-To: <20250324173121.1275209-10-mizhang@google.com> Precedence: bulk X-Mailing-List: linux-perf-users@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250324173121.1275209-1-mizhang@google.com> <20250324173121.1275209-10-mizhang@google.com> Message-ID: Subject: Re: [PATCH v4 09/38] perf: Add switch_guest_ctx() interface From: Sean Christopherson To: Mingwei Zhang Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Paolo Bonzini , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , Liang@google.com, Kan , "H. Peter Anvin" , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, Yongwei Ma , Xiong Zhang , Dapeng Mi , Jim Mattson , Sandipan Das , Zide Chen , Eranian Stephane , Shukla Manali , Nikunj Dadhania Content-Type: text/plain; charset="us-ascii" On Mon, Mar 24, 2025, Mingwei Zhang wrote: > From: Kan Liang > > When entering/exiting a guest, some contexts for a guest have to be > switched. For examples, there is a dedicated interrupt vector for > guests on Intel platforms. > > When PMI switch into a new guest vector, guest_lvtpc value need to be > reflected onto HW, e,g., guest clear PMI mask bit, the HW PMI mask > bit should be cleared also, then PMI can be generated continuously > for guest. So guest_lvtpc parameter is added into perf_guest_enter() > and switch_guest_ctx(). > > Add a dedicated list to track all the pmus with the PASSTHROUGH cap, which > may require switching the guest context. It can avoid going through the > huge pmus list. > > Suggested-by: Peter Zijlstra (Intel) > Signed-off-by: Kan Liang > Signed-off-by: Mingwei Zhang > --- > include/linux/perf_event.h | 17 +++++++++++-- > kernel/events/core.c | 51 +++++++++++++++++++++++++++++++++++++- > 2 files changed, 65 insertions(+), 3 deletions(-) > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h > index 37187ee8e226..58c1cf6939bf 100644 > --- a/include/linux/perf_event.h > +++ b/include/linux/perf_event.h > @@ -584,6 +584,11 @@ struct pmu { > * Check period value for PERF_EVENT_IOC_PERIOD ioctl. > */ > int (*check_period) (struct perf_event *event, u64 value); /* optional */ > + > + /* > + * Switch guest context when a guest enter/exit, e.g., interrupt vectors. > + */ > + void (*switch_guest_ctx) (bool enter, void *data); /* optional */ IMO, putting this in "struct pmu" is unnecessarily convoluted and complex, and a poor fit for what needs to be done. The only usage of the hook is for the CPU to swap the LVTPC, and the @data payload communicates exactly that. I.e. this has one user, and can't reasonably be extended to other users without some ugliness. And if by some miracle there's no CPU pmu in perf, KVM's mediated PMU still needs to swap to its PMI IRQ. So rather than per-PMU hook along with a list and a spinlock, just make this an arch hook. And if all of the mediated PMU code is guarded by a Kconfig, then perf doesn't even needs __weak stubs.