From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.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 7D06170818 for ; Fri, 17 Apr 2026 00:23:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776385415; cv=none; b=hfZKo8UR9lOI3S/lIgwvrrhabzQO5DnQHI7Ky214dbNpf5goNujSSHUNmBnKuuOvUYjzlK61GWjXwrRQEnB2agqD0ugyhLJ+TU6uZDkyyWNN9KGSxQNXxpApeTH3mGUXR8fOZkqvLL/U8qrsDj1tji6hdnhLS2plE1daahxr2Cg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776385415; c=relaxed/simple; bh=/aqm4WRoWHn1sLZRYKE22jwj4n1vdAS03UEkXoVry9U=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=AQ4ZH6vHq2AnCx4q73Xi+Mjb2bwSkMCtlfYYzhkwULteDIVK4hGMIVisMwW47RCKZZYPyIoNEKl+RwslL+HHD60OthyNYtxQhsYZS9JTiyR7207265snmaoAS5/j6ebRfKuVVfquYGdYxJVEBPsEn7QX302/1XVMS3PoidOJksA= 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=R9ue0zNp; arc=none smtp.client-ip=209.85.210.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="R9ue0zNp" Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-82f543bae3cso87320b3a.1 for ; Thu, 16 Apr 2026 17:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1776385414; x=1776990214; 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=LKQIMmt8g6K9uGClGEbvFNEwh+zq6tLKWRUCGQ1b2aU=; b=R9ue0zNpHPS2aYrhXj8YPxP8YTxRlveX+VIRp0VqJ6qOXija4n6rgknlWLcKSsedsc bZtXFLIBi+uzcA4xzH/gnoZO18xaV8xVVyxkH8n72hz4tFGC9+E3csr+SVhcDnJqQY+6 8cWekTf+SOwg4wOsxIfIQ0t15q+YhrU++rnfLWGGlsotkXzeHiKmIkRgLaDGOp0uFsIJ 68wx+6HORhUPCRywMry2hgHwHxM4lRxAd2xnn6NyKvrwuPowQ9+s50xRReYt6P28m4Dh kZFlBRwCVOC9V3arI7kiYhbJRelaStjGdRxBKawTyL6Puqg/PADaMYZLqMVZRfsA/OAM w9DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776385414; x=1776990214; 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=LKQIMmt8g6K9uGClGEbvFNEwh+zq6tLKWRUCGQ1b2aU=; b=enhjL0lv2VrpcYAPIuife5Cm/kJNXeY6CdG5vsdAl+pARm75FgXt2FC7OyB0qypuXV eXc1mMPiJuIewoSYVBovZxV09SxYX7uiJTmjG41ZAiW5Wgx5G5h34h/FoYkPPdmim5at aWl//c9A/vguW+wT06uvyMamPvsN4UWSgYYCb93qkMVGJuoyV/9x53j95r0F+Ahxl8nK XCoisy4Dpro06hcpmxkolbMroeoBKXVhza/6ixPoE4qLGJQNK714isHCje66GfexjHaw 27YX7GL8k5JGGOB+WS2+L3PpkgET06VAgNbBIwsEGTd51tQDXGxak3a0YhJiaHVpshao Uw7A== X-Forwarded-Encrypted: i=1; AFNElJ+htqDbly5EVXtBZHHwaNdtsKrcn5aJ5Sx0M1s37tzUt9JBY3VV4SAQ5SYOpxJ1Rnp6zwA=@vger.kernel.org X-Gm-Message-State: AOJu0YzOQK2byVM42Sukl4wry0to+PBX42uTXYU1gko13U2f08BTovoy PGZFk4f4GrXrC+fu26uVl0BSz20J6L4qsQljcan3qTmQ/KTyedkNZ42w/xDOM+jRqmeKt8FJrkK pG2sWig== X-Received: from pfoh24.prod.google.com ([2002:aa7:86d8:0:b0:82f:7d76:22f6]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:2d88:b0:829:6f7d:3086 with SMTP id d2e1a72fcca58-82f8b3aff42mr485749b3a.11.1776385413608; Thu, 16 Apr 2026 17:23:33 -0700 (PDT) Date: Thu, 16 Apr 2026 17:23:32 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260414191425.2697918-1-seanjc@google.com> <20260414191425.2697918-2-seanjc@google.com> Message-ID: Subject: Re: [PATCH 1/4] perf/x86/intel: Don't write PEBS_ENABLED on host<=>guest xfers if CPU has isolation From: Sean Christopherson To: Namhyung Kim Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, Paolo Bonzini , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Jim Mattson , Mingwei Zhang , Stephane Eranian , Dapeng Mi Content-Type: text/plain; charset="us-ascii" On Thu, Apr 16, 2026, Namhyung Kim wrote: > On Thu, Apr 16, 2026 at 12:38:49PM -0700, Sean Christopherson wrote: > > On Thu, Apr 16, 2026, Namhyung Kim wrote: > > > > + /* > > > > + * 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 &= kvm_pmu->pebs_enable & ~kvm_pmu->host_cross_mapped_mask; > > > > + if (pebs_mask & ~cpuc->intel_ctrl_guest_mask) > > > > + guest_pebs_mask = 0; > > > > > > > > + /* > > > > + * 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 |= guest_pebs_mask; > > > > > > I was confused by the earlier comment in the funcion that says it is not > > > enough to disable counters but I've realized it's only for the case PEBS > > > isolation is not supported by CPU/ucode. > > > > Yeah, me too, more than once. :-/ > > > > > I think it's ok for disabling guest PEBS, but I'm curious if there's a > > > case to enable PEBS only in guest and it'd be handled correctly. > > > > Yep, if PEBS is being virtualized for the guest, unless the host is also profiling, > > then PEBS will be active for the guest but not the host. KVM tests for PEBS pass, > > and while they aren't exactly comprehensive, they should detect outright breakage. > > In that case, wouldn't it need to update PEBS_ENABLED here? No, because KVM only supports guest usage of PEBS when KVM is proxying the guest PMU via perf. I.e. when perf fully controls PEBS_ENABLED. On perf's side, events created by KVM show up as "guest only", but are otherwise programmed normally, including getting shoved into PEBS_ENABLED as needed. So to activate PEBS PMCs for the guest, KVM just needs to load PERF_GLOBAL_CTRL with the counters that should be enabled for the guest (taking care to not load "guest only" PEBS events that were (stupidly) created by host userspace, as those can crash the guest.