From mboxrd@z Thu Jan 1 00:00:00 1970 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 5B7E128134F for ; Thu, 18 Dec 2025 18:40:53 +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=1766083256; cv=none; b=b8HskQ8KWk03XZ0UvG3xgLdV568rDRSdF7oryA/icNPJeH7vG6IjGaeUQ1rSOj/ywDbbGEBqlWapCr/3V8g/AVHXkNBwxrX5+Owtjb8a92KMCd3sLtw8YdAsQXqO/YeOdWoCChG/fGYGSJyy4duJCbAMdh/g8NEna5chRzNjgKI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766083256; c=relaxed/simple; bh=RYYbsSApLUmSiLGjx9MRR/PKwa64iCnAviHCFLXAP7s=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=nm0KDqXjnwwxioxLovr01OLcFmQIj57+N77bKAY2L58I0aAN8h/kqFNA6VBANxo+y3C10E7qxOvDmczMVhopqpinQi+CSsPQdN6eQL2SdeWj9Iv5LrgoQd/WUxO4VnzBI65teoIApBkbBFzCqU3BkHvlDDEwb9cF8WURXHBDFxA= 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=3ClhuB3A; 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="3ClhuB3A" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-34c213419f5so861033a91.2 for ; Thu, 18 Dec 2025 10:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1766083253; x=1766688053; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=qXXqU4jbywOmCfyBbesOdSVLl4kVgayMGQ9AhPMyorU=; b=3ClhuB3A4RlYnrJabgTSEFwDRJjGvObPbGkKi/3wxjlxcf6E+YoJp9hnRZf/yzysIU EQQVVgCrRU6Y41CUDDDwUlOPe5k1bQwQdrDeiCIEQG8CxMJxFildW+Sdadw2MW5cMiwN 85CHMPOSe3wVo3ygvwuJD7zFlkKyoq8kUjlDoos+94pphxFVa/Q7DncQKjPO+H4iJKr7 cq5gezszCcbqnWAlLysvY8va8ITWeEhtVnVDlVXP5Aiu7ENOLgDKxaxmudMbCfBuwOVD uRq7RQS154l+OdXdC2Q2mZuSgVR3aNUrJfOSvX6Ya51y1HyT8epAkuyJvvp/zSHEQEq7 vF5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766083253; x=1766688053; h=content-transfer-encoding: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=qXXqU4jbywOmCfyBbesOdSVLl4kVgayMGQ9AhPMyorU=; b=epWm8HFUToNxiO+yDde3NX/oR8SjL0EGzldoJ8dOQudurjRED0USaKfrOVoc/2vpPX Ua08q4qBUBpxj1Hpo0aPvew1dzTvbJvQ3IFBP7q2v8NGu686PUPSdzwABfiZDXN4hWAO Hf/rZvlWOGiThbzXYWLPNzvX6EQetiIBLWAFbx9+IjlLR9SOpOrsIOSGrlwsTpljWxjH w8SyOP2hZNgOKsppJSrV+SaBwy8I6/PlZspPKFeEqHFiiuX86FV8EyZrKgl4etdHZ/2f eg1A6tVTd1fvOX8dK/Cl2ClQMaE+3hhVX3DMXrbfSlRg9Z7DPo2QNGihNRegk6ySJ7no PKqg== X-Gm-Message-State: AOJu0YyB2GVlzUGk5zAZepe1OmlyrDFbw/SwR064f3xMdzRWt6aWwJ3t QkzWV7bKHmjnILTl7aZpwYejWXm5pRX9LmZPFWyNnRti3jfKuDpwJcP02q2hzu2/WovG0qh2WUh YA7kIww== X-Google-Smtp-Source: AGHT+IHwIK+8v+VK9tU3i7xm3ePKwmKmQsQMB3JoeqAXbjt4LHZxEpdn/la1a2+MaxxOCof88uAiv0k1myM= X-Received: from pjbgq23.prod.google.com ([2002:a17:90b:1057:b0:34c:ab9b:76d2]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90a:e7c9:b0:32e:7340:a7f7 with SMTP id 98e67ed59e1d1-34e921131admr254464a91.2.1766083252671; Thu, 18 Dec 2025 10:40:52 -0800 (PST) Date: Thu, 18 Dec 2025 10:40:51 -0800 In-Reply-To: <20251218083346.GG3708021@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20251208115156.GE3707891@noisy.programming.kicks-ass.net> <176597507731.510.6380001909229389563.tip-bot2@tip-bot2> <20251218083109.GH3707891@noisy.programming.kicks-ass.net> <20251218083346.GG3708021@noisy.programming.kicks-ass.net> Message-ID: Subject: Re: [tip: perf/core] perf: Use EXPORT_SYMBOL_FOR_KVM() for the mediated APIs From: Sean Christopherson To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, sfr@canb.auug.org.au, linux-tip-commits@vger.kernel.org, x86@kernel.org, pbonzini@redhat.com, kvm@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 18, 2025, Peter Zijlstra wrote: > On Thu, Dec 18, 2025 at 09:31:09AM +0100, Peter Zijlstra wrote: > > On Wed, Dec 17, 2025 at 12:37:57PM -0000, tip-bot2 for Peter Zijlstra w= rote: > > > diff --git a/kernel/events/core.c b/kernel/events/core.c > > > index e6a4b1e..376fb07 100644 > > > --- a/kernel/events/core.c > > > +++ b/kernel/events/core.c > > > @@ -57,6 +57,7 @@ > > > #include > > > #include > > > #include > > > +#include > > Bah, so the !KVM architectures hate on this. > >=20 > > Sean, would something like this be acceptable? >=20 > Hmm, the other option is doing something like so: >=20 > diff --git a/kernel/events/core.c b/kernel/events/core.c > index 376fb07d869b..014d832e8eaa 100644 > --- a/kernel/events/core.c > +++ b/kernel/events/core.c > @@ -57,7 +57,6 @@ > #include > #include > #include > -#include > =20 > #include "internal.h" > =20 > @@ -6325,6 +6324,8 @@ u64 perf_event_pause(struct perf_event *event, bool= reset) > EXPORT_SYMBOL_GPL(perf_event_pause); > =20 > #ifdef CONFIG_PERF_GUEST_MEDIATED_PMU > +#include Hrm, quick and dirty, but I don't love the idea of punting on the underlyin= g issue, because not being able to include kvm_types.h will be a big deterren= t to using EXPORT_SYMBOL_FOR_KVM(). > static atomic_t nr_include_guest_events __read_mostly; > =20 > static atomic_t nr_mediated_pmu_vms __read_mostly; >=20 > > --- > > Subject: kvm: Fix linux/kvm_types.h for !KVM architectures > >=20 > > As is, hard relies on architectures having > > which (obviously) breaks for architectures that don't > > have KVM support. > >=20 > > This means generic code (kernel/events/ in this case) cannot use > > EXPORT_SYMBOL_FOR_KVM(). > >=20 > > Rearrange things just so that becomes usable and > > provides the (expected) empty stub for EXPORT_SYMBOL_FOR_KVM() for !KVM= . > >=20 > > Signed-off-by: Peter Zijlstra (Intel) > > --- > > diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h > > index a568d8e6f4e8..a4cc13e41eec 100644 > > --- a/include/linux/kvm_types.h > > +++ b/include/linux/kvm_types.h > > @@ -6,6 +6,8 @@ > > #include > > #include > > #include > > + > > +#ifdef CONFIG_KVM > > #include This won't work, because asm/kvm_types.h #defines KVM_ARCH_NR_OBJS_PER_MEMO= RY_CACHE, which guards the "struct kvm_mmu_memory_cache" definition. E.g. on x86 wit= h CONFIG_KVM=3Dn, that yields errors like: In file included from include/linux/kvm_host.h:45, from arch/x86/events/intel/core.c:17: arch/x86/include/asm/kvm_host.h:854:37: error: field =E2=80=98mmu_pte_lis= t_desc_cache=E2=80=99 has incomplete type 854 | struct kvm_mmu_memory_cache mmu_pte_list_desc_cache; | ^~~~~~~~~~~~~~~~~~~~~~~ In general, I'm hesitant to guard an include with a conditional Kconfig, pr= ecisely because doing so has a tendency to result in wonky, config-specific build e= rrors. Rather than gate the check on KVM being enabled, what if we restrict the as= m include to architectures that support KVM in any capacity? Alternatively, = we could add a HAVE_KVM, but I'd rather not add HAVE_KVM, because then we'll e= nd up with the same mess if architectures get clever and conditionally select HAV= E_KVM (IIRC, that's exactly what happened when HAVE_KVM was a thing in the past). Compiled tested on all KVM architectures along with csky (and an include of kvm_types.h in init/main.c). -- From: Sean Christopherson Date: Thu, 18 Dec 2025 15:47:59 +0000 Subject: [PATCH] KVM: Allow linux/kvm_types.h to be included on non-KVM architectures Include the arch-defined asm/kvm_types.h if and only if the kernel is being compiled for an architecture that supports KVM so that kvm_types.h can be included in generic code without having to guard _those_ includes, and without having to add "generic-y +=3D kvm_types.h" for all architecture= s that don't support KVM. Assert that KVM=3Dn if asm/kvm_types.h isn't included to provide a more helpful error message if an arch name changes (highly unlikely) or a new arch that supports KVM comes along. Signed-off-by: Sean Christopherson --- include/linux/kvm_types.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h index a568d8e6f4e8..797721e298df 100644 --- a/include/linux/kvm_types.h +++ b/include/linux/kvm_types.h @@ -6,7 +6,23 @@ #include #include #include + +/* + * Include the arch-defined kvm_types.h if and only if the target architec= ture + * supports KVM, so that linux/kvm_types.h can be included in generic code + * without requiring _all_ architectures to add generic-y +=3D kvm_types.h= . + */ +#if defined(CONFIG_ARM64) || \ + defined(CONFIG_LOONGARCH) || \ + defined(CONFIG_MIPS) || \ + defined(CONFIG_PPC) || \ + defined(CONFIG_RISCV) || \ + defined(CONFIG_S390) || \ + defined(CONFIG_X86) #include +#else +static_assert(!IS_ENABLED(CONFIG_KVM)); +#endif =20 #ifdef KVM_SUB_MODULES #define EXPORT_SYMBOL_FOR_KVM_INTERNAL(symbol) \ base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 --=20