On Tue, 28 Jul 2026 at 10:33, Akihiko Odaki
<[email protected]> wrote:
>
> On 2026/07/28 1:10, Peter Maydell wrote:
> > On Mon, 29 Jun 2026 at 09:10, Akihiko Odaki
> > <[email protected]> wrote:
> >>
> >> kvm-steal-time and sve properties are added for KVM even if the
> >> corresponding features are not available. Always add pmu property for
> >> "host" and "max".
> >>
> >> Note that we still don't add the property for other CPUs that lack PMU.
> >> This is because we do not know what a PMU version should be enabled
> >> when the user sets the property to true while it is defined as an error
> >> for the "host" or "max" CPU when the hardware accelerator is enabled and
> >> the host doesn't have a PMU.
> >>
> >> This fixes qtest-aarch64/arm-cpu-features on the hosts that supports
> >> KVM but doesn't support PMU emulation.
> >
> > No, we should not special case "host" and "max" like this.
> > The "pmu" property exists only if the CPU has a PMU and it can
> > be turned off. If The arm-cpu-features test assumes that the
> > host CPU always has a PMU and so always has the property, then
> > that's a bug in the test, not in the code handling the property.
>
> The test correctly avoids assuming that the host always has a PMU. It
> expects that the run-time-derived "host" CPU has a stable "pmu"
> property, with its value reporting whether PMU is available.
That is not a valid expectation currently, because that's not
how the property behaves (and is not how many of the Arm CPU
properties behave). If we (as has been proposed) refactor Arm CPU
properties so that they're class properties rather than object
properties then we will have a property that is present always.
I don't inherently object to doing that.
> That is already how Arm handles SVE. Commit d25293068b03 ("target/arm:
> Move kvm test out of cpu_arm_set_sve") added a false SVE property when
> KVM lacks SVE. PAuth and kvm-steal-time use the same general model.
> Other architectures do the similar; for example LoongArch KVM does
> exactly this for "pmu". So we are avoiding special-casing the Arm pmu
> property here.
>
> The comment in aarch64_add_sve_properties() gives the rationale
> explicitly: "to allow -cpu max,sve=off to always be valid." sve=on still
> fails in that case. Keeping the property stable prevents -cpu
> host,pmu=off from becoming invalid on hosts where the PMU cannot be
> enabled. This also matters outside the test: libvirt emits pmu=off when
> the PMU is explicitly disabled. This design is intended to follow the
> alternative you described previously [1].
>
> "host" and "max" are special-cased for a different reason. For fixed Arm
> CPU models, the property is omitted because its semantics is not defined
> when they don't have PMUs. "host" and "max" are different: "host" and
> "max" enable whatever PMU available, and fail otherwise.
We should not special case "host" and "max". If we want an "always present"
property then its semantics should be:
- always exists for all CPUs
- if the CPU can't support a PMU then you can't set it to "on"
-- PMM
