From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yb1-f202.google.com (mail-yb1-f202.google.com [209.85.219.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 E0E5D15EFA2 for ; Wed, 24 Apr 2024 15:00:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713970827; cv=none; b=ZkNN8zEBOQVAL9FJP/tmGFXfvDJZnxIZt1/BSnF+gwUJ8LyQ7Yu/FLASZKVX9AGC2ZT4s1RULl0gO2iKQZahL4xTDZUKhduU3oWMPuTqJrdJ4PVSTpCq4OaJebDTzifD6230vgGUppbwJaXkFNJZ8nnJDarxrco0GWya5GTNMRs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713970827; c=relaxed/simple; bh=m2kvDOjAcs0/fOGssqgm6z3aXoukHOTqP1RoSeztxz4=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=B6qFqAXP7usaE3fsrq5U8DWixcThxX5U0bAIghzBkFi2zKq6ObvZc519NdX7LOzz9xhHRT2U3MuwOCIjwxtePd+yCoxE/hr37H2JOC+wNYPCWaRNo6C1d94jRoMP3qAjgShCuUM1AnmDbA5bR4wYE7GOaU9zN9rGN5GeqeyLgow= 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=q64toCyl; arc=none smtp.client-ip=209.85.219.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="q64toCyl" Received: by mail-yb1-f202.google.com with SMTP id 3f1490d57ef6-dc6b26783b4so9888113276.0 for ; Wed, 24 Apr 2024 08:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1713970825; x=1714575625; 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=iTow4IhQ+Q7ezsDpFxCw9QP7cHw66mii0qlTGERXHWI=; b=q64toCyl3FC9eb9bdPgLikX+Tg+qejWAbhRj/hveXefzZhVP161I/nwDjJUk0BoR5Q EjKiIr/GERKHwP2SqmpJbmzAsBwbyUI5bJhE66Bwrz42FYHViH8fBNjtRt/9TTo9eP3b 0aXnV4Ed87SttaL0ihb4IngpJE4PsSHQEp0Hn9Uyz5vWdP70pGi29sqkxvCJkGkOLjh3 EDiZvv/z8s1ccpQS9iMvlfoZonilL130jm8Qs+jRRnLWjdP998/M2+O5zSyONEFISBob vP6sjh0hMY4Ihg1lSb01sVaLIV09s3ulOEYyXkXvshWNUTKTff1V7Un/FXYwO+kZYD/G SCUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713970825; x=1714575625; 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=iTow4IhQ+Q7ezsDpFxCw9QP7cHw66mii0qlTGERXHWI=; b=Cgc9pAVjWagBeEQrB4nJcwKVzVCR9k+WulP6x3LgmbHftn2B5m3jQBUdWerKd8eGyB TFm/Tvu/ZT2tNzw+8WXLSP4NHxzgS9Z5O94IDyiLZOVezf/h3giDbGvGw1iJ1HoEeV9D qW+D6Gn+2uKgrfwVBq6TVOuJjie4YvFDip3oZJDkd/ZrHGqwJUpguTvEDdH/4qI+rw0z av9ZGsDAXSyBnqkx8xFyQrNpZtxHzy1HUSpUAhzavUnipj8gjAOjnnQI2ZWt/ZrslUFU 4YFIleNJ3bPL/YOczP4AysOiuZCSzZCskEpLq6IJOaxbOPiRHh20hGDnJts0ZezvET5w taFQ== X-Forwarded-Encrypted: i=1; AJvYcCXvTo1WWfbzpJNXR2fW5BOlZDAUWITAGkIcKN+KCCl4mynSQGGo09uCky9kZScLcD0urq9lz+IUFzIsM66cLuBchG352IYEmfdS/+4c X-Gm-Message-State: AOJu0Yy1WS16bVanY3CgE69jyJS5TCPzztLHyyzBGzbEufudWKd1DSmt U9BhMG/5aEUN/rajyzG7ZvF71ijc3WmFCHG3WE+0dvBAbmyTdZYtloS20CAoAGpiRFq/eHN2X3c sKg== X-Google-Smtp-Source: AGHT+IFFD+SYfagl/TClvPMU0JQ850YCyw4YR2sbV6rmuRkaHu0K9DZ/AAPWyBohe3gIvA3eeokv75tdbZA= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:ce12:0:b0:de5:1ea2:fc75 with SMTP id x18-20020a25ce12000000b00de51ea2fc75mr219027ybe.7.1713970824986; Wed, 24 Apr 2024 08:00:24 -0700 (PDT) Date: Wed, 24 Apr 2024 08:00:23 -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: <1ec7a21c-71d0-4f3e-9fa3-3de8ca0f7315@linux.intel.com> <5279eabc-ca46-ee1b-b80d-9a511ba90a36@loongson.cn> Message-ID: Subject: Re: [RFC PATCH 23/41] KVM: x86/pmu: Implement the save/restore of PMU state for Intel CPU From: Sean Christopherson To: Dapeng Mi Cc: Mingwei Zhang , maobibo , Xiong Zhang , pbonzini@redhat.com, peterz@infradead.org, kan.liang@intel.com, zhenyuw@linux.intel.com, jmattson@google.com, kvm@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, zhiyuan.lv@intel.com, eranian@google.com, irogers@google.com, samantha.alt@intel.com, like.xu.linux@gmail.com, chao.gao@intel.com Content-Type: text/plain; charset="us-ascii" On Wed, Apr 24, 2024, Dapeng Mi wrote: > > On 4/24/2024 1:02 AM, Mingwei Zhang wrote: > > > > Maybe, (just maybe), it is possible to do PMU context switch at vcpu > > > > boundary normally, but doing it at VM Enter/Exit boundary when host is > > > > profiling KVM kernel module. So, dynamically adjusting PMU context > > > > switch location could be an option. > > > If there are two VMs with pmu enabled both, however host PMU is not > > > enabled. PMU context switch should be done in vcpu thread sched-out path. > > > > > > If host pmu is used also, we can choose whether PMU switch should be > > > done in vm exit path or vcpu thread sched-out path. > > > > > host PMU is always enabled, ie., Linux currently does not support KVM > > PMU running standalone. I guess what you mean is there are no active > > perf_events on the host side. Allowing a PMU context switch drifting > > from vm-enter/exit boundary to vcpu loop boundary by checking host > > side events might be a good option. We can keep the discussion, but I > > won't propose that in v2. > > I suspect if it's really doable to do this deferring. This still makes host > lose the most of capability to profile KVM. Per my understanding, most of > KVM overhead happens in the vcpu loop, exactly speaking in VM-exit handling. > We have no idea when host want to create perf event to profile KVM, it could > be at any time. No, the idea is that KVM will load host PMU state asap, but only when host PMU state actually needs to be loaded, i.e. only when there are relevant host events. If there are no host perf events, KVM keeps guest PMU state loaded for the entire KVM_RUN loop, i.e. provides optimal behavior for the guest. But if a host perf events exists (or comes along), the KVM context switches PMU at VM-Enter/VM-Exit, i.e. lets the host profile almost all of KVM, at the cost of a degraded experience for the guest while host perf events are active. My original sketch: https://lore.kernel.org/all/ZR3eNtP5IVAHeFNC@google.com