All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: Akihiko Odaki <akihiko.odaki@daynix.com>,
	Joey Gouly <joey.gouly@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Kees Cook <kees@kernel.org>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
	devel@daynix.com
Subject: Re: [PATCH RFC] KVM: arm64: PMU: Use multiple host PMUs
Date: Thu, 20 Mar 2025 17:44:03 +0000	[thread overview]
Message-ID: <Z9xT4_fwCgp7VSgC@linux.dev> (raw)
In-Reply-To: <86h63om54p.wl-maz@kernel.org>

On Thu, Mar 20, 2025 at 09:19:02AM +0000, Marc Zyngier wrote:
> On Wed, 19 Mar 2025 18:51:28 +0000, Oliver Upton <oliver.upton@linux.dev> wrote:
> > I'm at least willing to plug my nose and do the following:
> > 
> >  1) When the VMM does not specify a vPMU type:
> > 
> >    - We continue to present the 'default' PMU (including event counters)
> >      to the VM
> > 
> >    - KVM ensures that the fixed CPU cycle counter works on any PMUv3
> >      implementation in the system, even if it is different from the
> >      default
> > 
> >    - Otherwise, event counters will only count on the default
> >      implementation and will not count on different PMUs
> 
> I think this is confusing. The CC is counting, but nothing else, and
> people using the cycle counters in conjunction with other events (a
> very common use case) will not be able to correlate things correctly.
> The current behaviour is, for all its sins, at least consistent.

You of course have a good point. What Windows is doing is definitely an
outlier.

> > 
> >  2) Implement your suggestion of a UAPI where the VMM can select a PMU
> >     that only has the CPU cycle counter and works on any PMUv3
> >     implementation.
> > 
> > Either way KVM will need to have some special case handling of the fixed
> > CPU cycle counter. That'd allow users to actually run Windows *now* and
> > provide a clear mechanism for userspace to present a less-broken vPMU if
> > it cares.
> 
> Honestly, I don't care about one guest or another. My point is that if
> we are changing the behaviour of the PMU to deal with this sort of
> things, then it has to be a userspace buy-in.

I'm fine with just the user buy-in then. But I still do care about the
guest compatibility issue, especially since the end user of all this
crap is unlikely to know/care about the fine details of the
implementation.

So, Akihiko, I would *greatly* appreciate it if you propose a complete
solution to the problem, including the KVM and VMM patches to make it
all work.

Thanks,
Oliver

      reply	other threads:[~2025-03-20 17:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-19  6:33 [PATCH RFC] KVM: arm64: PMU: Use multiple host PMUs Akihiko Odaki
2025-03-19  7:34 ` Oliver Upton
2025-03-19  8:37   ` Akihiko Odaki
2025-03-19  9:47     ` Marc Zyngier
2025-03-19 10:26       ` Akihiko Odaki
2025-03-19 11:07         ` Marc Zyngier
2025-03-19 11:26           ` Akihiko Odaki
2025-03-19 11:41             ` Marc Zyngier
2025-03-19 11:51               ` Akihiko Odaki
2025-03-19 18:38                 ` Marc Zyngier
2025-03-19 18:51                   ` Oliver Upton
2025-03-20  6:03                     ` Akihiko Odaki
2025-03-20  9:10                       ` Marc Zyngier
2025-03-20  9:52                         ` Akihiko Odaki
2025-03-20 17:14                           ` Marc Zyngier
2025-03-21  6:20                             ` Akihiko Odaki
2025-03-21 10:59                               ` Marc Zyngier
2025-03-20  9:19                     ` Marc Zyngier
2025-03-20 17:44                       ` Oliver Upton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z9xT4_fwCgp7VSgC@linux.dev \
    --to=oliver.upton@linux.dev \
    --cc=akihiko.odaki@daynix.com \
    --cc=catalin.marinas@arm.com \
    --cc=devel@daynix.com \
    --cc=gustavoars@kernel.org \
    --cc=joey.gouly@arm.com \
    --cc=kees@kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.