<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/arch/arm64/kvm/sys_regs.c, branch linux-6.2.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.2.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.2.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2023-04-20T10:36:52Z</updated>
<entry>
<title>KVM: arm64: PMU: Restore the guest's EL0 event counting after migration</title>
<updated>2023-04-20T10:36:52Z</updated>
<author>
<name>Reiji Watanabe</name>
<email>reijiw@google.com</email>
</author>
<published>2023-03-29T02:39:44Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0cc6fdf79bb0ad15e3f9e4a08db0ba200da04dee'/>
<id>urn:sha1:0cc6fdf79bb0ad15e3f9e4a08db0ba200da04dee</id>
<content type='text'>
commit f9ea835e99bc8d049bf2a3ec8fa5a7cb4fcade23 upstream.

Currently, with VHE, KVM enables the EL0 event counting for the
guest on vcpu_load() or KVM enables it as a part of the PMU
register emulation process, when needed.  However, in the migration
case (with VHE), the same handling is lacking, as vPMU register
values that were restored by userspace haven't been propagated yet
(the PMU events haven't been created) at the vcpu load-time on the
first KVM_RUN (kvm_vcpu_pmu_restore_guest() called from vcpu_load()
on the first KVM_RUN won't do anything as events_{guest,host} of
kvm_pmu_events are still zero).

So, with VHE, enable the guest's EL0 event counting on the first
KVM_RUN (after the migration) when needed.  More specifically,
have kvm_pmu_handle_pmcr() call kvm_vcpu_pmu_restore_guest()
so that kvm_pmu_handle_pmcr() on the first KVM_RUN can take
care of it.

Fixes: d0c94c49792c ("KVM: arm64: Restore PMU configuration on first run")
Cc: stable@vger.kernel.org
Reviewed-by: Marc Zyngier &lt;maz@kernel.org&gt;
Signed-off-by: Reiji Watanabe &lt;reijiw@google.com&gt;
Link: https://lore.kernel.org/r/20230329023944.2488484-1-reijiw@google.com
Signed-off-by: Oliver Upton &lt;oliver.upton@linux.dev&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: PMU: Fix GET_ONE_REG for vPMC regs to return the current value</title>
<updated>2023-04-06T10:12:47Z</updated>
<author>
<name>Reiji Watanabe</name>
<email>reijiw@google.com</email>
</author>
<published>2023-03-13T03:32:08Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a817c9667c59b1f6134c8aa97655c817738e3dda'/>
<id>urn:sha1:a817c9667c59b1f6134c8aa97655c817738e3dda</id>
<content type='text'>
commit 9228b26194d1cc00449f12f306f53ef2e234a55b upstream.

Have KVM_GET_ONE_REG for vPMU counter (vPMC) registers (PMCCNTR_EL0
and PMEVCNTR&lt;n&gt;_EL0) return the sum of the register value in the sysreg
file and the current perf event counter value.

Values of vPMC registers are saved in sysreg files on certain occasions.
These saved values don't represent the current values of the vPMC
registers if the perf events for the vPMCs count events after the save.
The current values of those registers are the sum of the sysreg file
value and the current perf event counter value.  But, when userspace
reads those registers (using KVM_GET_ONE_REG), KVM returns the sysreg
file value to userspace (not the sum value).

Fix this to return the sum value for KVM_GET_ONE_REG.

Fixes: 051ff581ce70 ("arm64: KVM: Add access handler for event counter register")
Cc: stable@vger.kernel.org
Reviewed-by: Marc Zyngier &lt;maz@kernel.org&gt;
Signed-off-by: Reiji Watanabe &lt;reijiw@google.com&gt;
Link: https://lore.kernel.org/r/20230313033208.1475499-1-reijiw@google.com
Signed-off-by: Oliver Upton &lt;oliver.upton@linux.dev&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: PMU: Fix PMCR_EL0 reset value</title>
<updated>2022-12-12T09:07:14Z</updated>
<author>
<name>James Clark</name>
<email>james.clark@arm.com</email>
</author>
<published>2022-12-09T16:44:46Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=aff234839f8b80ac101e6c2f14d0e44b236efa48'/>
<id>urn:sha1:aff234839f8b80ac101e6c2f14d0e44b236efa48</id>
<content type='text'>
ARMV8_PMU_PMCR_N_MASK is an unshifted value which results in the wrong
reset value for PMCR_EL0, so shift it to fix it.

This fixes the following error when running qemu:

  $ qemu-system-aarch64 -cpu host -machine type=virt,accel=kvm -kernel ...

  target/arm/helper.c:1813: pmevcntr_rawwrite: Assertion `counter &lt; pmu_num_counters(env)' failed.

Fixes: 292e8f149476 ("KVM: arm64: PMU: Simplify PMCR_EL0 reset handling")
Signed-off-by: James Clark &lt;james.clark@arm.com&gt;
Reviewed-by: Oliver Upton &lt;oliver.upton@linux.dev&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20221209164446.1972014-2-james.clark@arm.com
</content>
</entry>
<entry>
<title>Merge remote-tracking branch 'arm64/for-next/sysregs' into kvmarm-master/next</title>
<updated>2022-12-05T14:39:53Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2022-12-05T14:34:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=753d734f3f347e7fc49b819472bbf61dcfc1a16f'/>
<id>urn:sha1:753d734f3f347e7fc49b819472bbf61dcfc1a16f</id>
<content type='text'>
Merge arm64's sysreg repainting branch to avoid too many
ugly conflicts...

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64/sysreg: Standardise naming for ID_DFR0_EL1</title>
<updated>2022-12-01T15:53:14Z</updated>
<author>
<name>James Morse</name>
<email>james.morse@arm.com</email>
</author>
<published>2022-11-30T17:16:10Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f4f5969e354235bbe729ff3881089fc902c0daff'/>
<id>urn:sha1:f4f5969e354235bbe729ff3881089fc902c0daff</id>
<content type='text'>
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.

Ensure symbols for the ID_DFR0_EL1 register have an _EL1 suffix,
and use lower-case for feature names where the arm-arm does the same.

The arm-arm has feature names for some of the ID_DFR0_EL1.PerMon encodings.
Use these feature names in preference to the '8_4' indication of the
architecture version they were introduced in.

No functional change.

Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Link: https://lore.kernel.org/r/20221130171637.718182-12-james.morse@arm.com
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: PMU: Sanitise PMCR_EL0.LP on first vcpu run</title>
<updated>2022-11-28T14:04:08Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2022-11-24T10:44:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=64d6820d64c0a206e744bd8945374d563a76c16c'/>
<id>urn:sha1:64d6820d64c0a206e744bd8945374d563a76c16c</id>
<content type='text'>
Userspace can play some dirty tricks on us by selecting a given
PMU version (such as PMUv3p5), restore a PMCR_EL0 value that
has PMCR_EL0.LP set, and then switch the PMU version to PMUv3p1,
for example. In this situation, we end-up with PMCR_EL0.LP being
set and spreading havoc in the PMU emulation.

This is specially hard as the first two step can be done on
one vcpu and the third step on another, meaning that we need
to sanitise *all* vcpus when the PMU version is changed.

In orer to avoid a pretty complicated locking situation,
defer the sanitisation of PMCR_EL0 to the point where the
vcpu is actually run for the first tine, using the existing
KVM_REQ_RELOAD_PMU request that calls into kvm_pmu_handle_pmcr().

There is still an obscure corner case where userspace could
do the above trick, and then save the VM without running it.
They would then observe an inconsistent state (PMUv3.1 + LP set),
but that state will be fixed on the first run anyway whenever
the guest gets restored on a host.

Reported-by: Reiji Watanabe &lt;reijiw@google.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: PMU: Simplify PMCR_EL0 reset handling</title>
<updated>2022-11-28T14:04:08Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2022-11-24T10:40:02Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=292e8f1494764ac46dd1b7dd46fa317db691436c'/>
<id>urn:sha1:292e8f1494764ac46dd1b7dd46fa317db691436c</id>
<content type='text'>
Resetting PMCR_EL0 is a pretty involved process that includes
poisoning some of the writable bits, just because we can.

It makes it hard to reason about about what gets configured,
and just resetting things to 0 seems like a much saner option.

Reduce reset_pmcr() to just preserving PMCR_EL0.N from the host,
and setting PMCR_EL0.LC if we don't support AArch32.

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: PMU: Implement PMUv3p5 long counter support</title>
<updated>2022-11-19T12:56:39Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2022-11-13T16:38:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=11af4c37165e36a6090172ded5d06acdf15206da'/>
<id>urn:sha1:11af4c37165e36a6090172ded5d06acdf15206da</id>
<content type='text'>
PMUv3p5 (which is mandatory with ARMv8.5) comes with some extra
features:

- All counters are 64bit

- The overflow point is controlled by the PMCR_EL0.LP bit

Add the required checks in the helpers that control counter
width and overflow, as well as the sysreg handling for the LP
bit. A new kvm_pmu_is_3p5() helper makes it easy to spot the
PMUv3p5 specific handling.

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20221113163832.3154370-14-maz@kernel.org
</content>
</entry>
<entry>
<title>KVM: arm64: PMU: Allow ID_DFR0_EL1.PerfMon to be set from userspace</title>
<updated>2022-11-19T12:56:39Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2022-11-13T16:38:28Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d82e0dfdfda73f91e7282e1083a2cd7cd366ea87'/>
<id>urn:sha1:d82e0dfdfda73f91e7282e1083a2cd7cd366ea87</id>
<content type='text'>
Allow userspace to write ID_DFR0_EL1, on the condition that only
the PerfMon field can be altered and be something that is compatible
with what was computed for the AArch64 view of the guest.

Reviewed-by: Reiji Watanabe &lt;reijiw@google.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20221113163832.3154370-13-maz@kernel.org
</content>
</entry>
<entry>
<title>KVM: arm64: PMU: Allow ID_AA64DFR0_EL1.PMUver to be set from userspace</title>
<updated>2022-11-19T12:56:39Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2022-11-13T16:38:27Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=60e651ff1f48bfdf8fec80d35510bd89ecf8c766'/>
<id>urn:sha1:60e651ff1f48bfdf8fec80d35510bd89ecf8c766</id>
<content type='text'>
Allow userspace to write ID_AA64DFR0_EL1, on the condition that only
the PMUver field can be altered and be at most the one that was
initially computed for the guest.

Reviewed-by: Reiji Watanabe &lt;reijiw@google.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20221113163832.3154370-12-maz@kernel.org
</content>
</entry>
</feed>
