qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: Thomas Huth <thuth@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>,
	 Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm@nongnu.org, qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [PATCH v2 4/5] target/arm: Always add pmu property
Date: Tue, 16 Jul 2024 13:53:52 +0100	[thread overview]
Message-ID: <CAFEAcA8qN3X2yaBjth=1a7kUCmYY32Ho9nG5e2tiL21QCw1DkA@mail.gmail.com> (raw)
In-Reply-To: <cdd5ce60-230f-48a1-bcf3-9591b8bede95@daynix.com>

On Tue, 16 Jul 2024 at 12:36, Akihiko Odaki <akihiko.odaki@daynix.com> wrote:
>
> On 2024/07/16 20:32, Peter Maydell wrote:
> > On Tue, 16 Jul 2024 at 09:28, Akihiko Odaki <akihiko.odaki@daynix.com> wrote:
> > Before we do this we need to do something to forbid setting
> > the pmu property to true on CPUs which don't have it. That is:
> >
> >   * for CPUs which do have a PMU, we should default to present, and
> >     allow the user to turn it on and off with pmu=on/off
> >   * for CPUs which do not have a PMU, we should not let the user
> >     turn it on and off (either by not providing the property, or
> >     else by making the property-set method raise an error, or by
> >     having realize detect the discrepancy and raise an error)
>
> I don't think there is any reason to prohibit adding a PMU to a CPU that
> doesn't have when you allow to remove one. For example, neoverse-v1
> should always have PMU in the real world.

For example, the Cortex-M3 doesn't have a PMU anything like the
A-profile one, so we shouldn't allow the user to set pmu=on.
The Arm1176 doesn't have a PMU like the one we emulate, so we
shouldn't allow the user to turn it on. All the CPUs where it
is reasonable and architecturally valid to have a PMU set the
ARM_FEATURE_PMU bit, so there (by design) is no CPU where that
bit isn't set by default but could reasonably be enabled by
the user.

Conversely, the PMUv3 is architecturally optional, so it's not
unreasonable to allow the user to disable it even if the
real-hardware Neoverse-V1 doesn't provide that as a config
option in the RTL.

thanks
-- PMM


  reply	other threads:[~2024-07-16 12:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-16  8:28 [PATCH v2 0/5] target/arm/kvm: Report PMU unavailability Akihiko Odaki
2024-07-16  8:28 ` [PATCH v2 1/5] tests/arm-cpu-features: Do not assume PMU availability Akihiko Odaki
2024-07-16  9:16   ` Philippe Mathieu-Daudé
2024-07-16  8:28 ` [PATCH v2 2/5] target/arm: Allow setting 'pmu' only for host and max Akihiko Odaki
2024-07-16  9:36   ` Peter Maydell
2024-07-16  8:28 ` [PATCH v2 3/5] target/arm: Do not allow setting 'pmu' for hvf Akihiko Odaki
2024-07-16 11:28   ` Peter Maydell
2024-07-16  8:28 ` [PATCH v2 4/5] target/arm: Always add pmu property Akihiko Odaki
2024-07-16  9:19   ` Philippe Mathieu-Daudé
2024-07-16 11:32   ` Peter Maydell
2024-07-16 11:36     ` Akihiko Odaki
2024-07-16 12:53       ` Peter Maydell [this message]
2024-07-16  8:28 ` [PATCH v2 5/5] target/arm/kvm: Report PMU unavailability Akihiko Odaki
2024-07-16  9:22   ` Philippe Mathieu-Daudé

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='CAFEAcA8qN3X2yaBjth=1a7kUCmYY32Ho9nG5e2tiL21QCw1DkA@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=akihiko.odaki@daynix.com \
    --cc=kvm@vger.kernel.org \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).