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 7F2F81607A4 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-82f543bae3cso87325b3a.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=r5Va8+xVwXQnho7dYHa13ysfv4UvK1bGN5uOh1CrEaGf+z3gRTOk4y2uRwnMtkFgBf JVCpjqHcqx9vsbhoHzy9gZPM9WoAB59JgL9le+N5+cetIy9vZLj8nVNV3J+4CSVeLt4E EB040gv+gHPV+YoYW+hSjDoAPB0uR3wd8JJlyNDuunYOSWIcwj8RmOp2ukYsi0F4K5wx gjefrEL1JfOCXn+sjZaw9snjfduFH2v/z3OsXygjqzwrClm+9XukFj9tjBk+S/VdujHx Hu9FOq3Q2vzw745WbOdgZT06OfRVLUp0UoIJMO0nLyrDjFnhMlf6bcQ5tVeLDV4sNkK6 r4bQ== X-Forwarded-Encrypted: i=1; AFNElJ9SWl3A/Fptkp6keYHVI88fXxzdaoxsOPI8uynbsQf2C/yfbwpqi/vvvbrj8spJD0t91NLGH/+h9qe0xhk=@vger.kernel.org X-Gm-Message-State: AOJu0Yxv/igsFHJIqEl5YUxJyTejZN4c4aa/s+KM2vn+W25mC6ckA8GU qK7AYtadZssq/vib8dLnFtU4SW+W8b9vQN9yxUqVBm6KhKFVchYPwjigGUf6/c9B5IJM0qDUIdV w4ZuQzw== 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: linux-kernel@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.