On 2026/07/28 18:40, Peter Maydell wrote:
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"
This patch follows the behavior of the sve property. Although sve is
registered with object_property_add_bool(), the presence of the property
is determined per class basis: the arm-cpu-host and arm-cpu-max classes
always expose it, while the other arm-cpu subclasses expose it only when
they support SVE.
As I quoted earlier, the SVE code explicitly documents why the property
should be always present for the host and max CPUs, and
qtest-aarch64/arm-cpu-features tests that along with the pmu property,
so I would prefer to maintain consistency here unless there is a reason
to do otherwise.
That said, the SVE code does not explain why the property must be
*absent* for fixed CPU models that lack the feature, so there is
certainly room to refine that design uniformly. Please note that the
current test case contains dead code asserting that the property is
absent on AArch32 CPUs when running KVM, which might need to be updated.
Regards,
Akihiko Odaki
