From: Marc Zyngier <maz@kernel.org>
To: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
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>,
linux-arm-kernel@lists.infradead.org,
Andrew Jones <andrew.jones@linux.dev>,
kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org,
devel@daynix.com
Subject: Re: [PATCH v2 3/3] KVM: arm64: PMU: Set raw values from user to PM{C,I}NTEN{SET,CLR}, PMOVS{SET,CLR}
Date: Sun, 09 Mar 2025 19:01:05 +0000 [thread overview]
Message-ID: <864j02owpa.wl-maz@kernel.org> (raw)
In-Reply-To: <20250307-pmc-v2-3-6c3375a5f1e4@daynix.com>
On Fri, 07 Mar 2025 10:55:30 +0000,
Akihiko Odaki <akihiko.odaki@daynix.com> wrote:
>
> Commit a45f41d754e0 ("KVM: arm64: Add {get,set}_user for
> PM{C,I}NTEN{SET,CLR}, PMOVS{SET,CLR}") changed KVM_SET_ONE_REG to update
> the mentioned registers in a way matching with the behavior of guest
> register writes. This is a breaking change of a UAPI though the new
> semantics looks cleaner and VMMs are not prepared for this.
>
> Firecracker, QEMU, and crosvm perform migration by listing registers
> with KVM_GET_REG_LIST, getting their values with KVM_GET_ONE_REG and
> setting them with KVM_SET_ONE_REG. This algorithm assumes
> KVM_SET_ONE_REG restores the values retrieved with KVM_GET_ONE_REG
> without any alteration. However, bit operations added by the earlier
> commit do not preserve the values retried with KVM_GET_ONE_REG and
> potentially break migration.
>
> Remove the bit operations that alter the values retrieved with
> KVM_GET_ONE_REG.
>
> Fixes: a45f41d754e0 ("KVM: arm64: Add {get,set}_user for PM{C,I}NTEN{SET,CLR}, PMOVS{SET,CLR}")
> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
> ---
> arch/arm64/kvm/sys_regs.c | 21 +--------------------
> 1 file changed, 1 insertion(+), 20 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 51054b7befc0b4bd822cecf717ee4a4740c4a685..2f44d4d4f54112787683dd75ea93fd60e92dd31f 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1142,26 +1142,7 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>
> static int set_pmreg(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r, u64 val)
> {
> - bool set;
> -
> - val &= kvm_pmu_valid_counter_mask(vcpu);
> -
> - switch (r->reg) {
> - case PMOVSSET_EL0:
> - /* CRm[1] being set indicates a SET register, and CLR otherwise */
> - set = r->CRm & 2;
> - break;
> - default:
> - /* Op2[0] being set indicates a SET register, and CLR otherwise */
> - set = r->Op2 & 1;
> - break;
> - }
> -
> - if (set)
> - __vcpu_sys_reg(vcpu, r->reg) |= val;
> - else
> - __vcpu_sys_reg(vcpu, r->reg) &= ~val;
> -
> + __vcpu_sys_reg(vcpu, r->reg) = val & kvm_pmu_valid_counter_mask(vcpu);
> kvm_make_request(KVM_REQ_RELOAD_PMU, vcpu);
>
> return 0;
>
Yup, this code was definitely a brain fart. Thanks for spotting it.
One of the big mistake was to expose both CLR and SET registers to
userspace (one of the two should have been hidden).
This requires a Cc to stable@vger.kernel.org so that this can be
backported to anything from 6.12. It would also help if you put this
patch at the head of the series, before adding the PMU request (it is
then likely to be very easy to backport).
With that,
Acked-by: Marc Zyngier <maz@kernel.org>
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
prev parent reply other threads:[~2025-03-09 19:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-07 10:55 [PATCH v2 0/3] KVM: arm64: PMU: Fix SET_ONE_REG for vPMC regs Akihiko Odaki
2025-03-07 10:55 ` [PATCH v2 1/3] " Akihiko Odaki
2025-03-09 18:40 ` Marc Zyngier
2025-03-07 10:55 ` [PATCH v2 2/3] KVM: arm64: PMU: Reload when user modifies registers Akihiko Odaki
2025-03-09 18:50 ` Marc Zyngier
2025-03-07 10:55 ` [PATCH v2 3/3] KVM: arm64: PMU: Set raw values from user to PM{C,I}NTEN{SET,CLR}, PMOVS{SET,CLR} Akihiko Odaki
2025-03-09 19:01 ` Marc Zyngier [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=864j02owpa.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=akihiko.odaki@daynix.com \
--cc=andrew.jones@linux.dev \
--cc=catalin.marinas@arm.com \
--cc=devel@daynix.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oliver.upton@linux.dev \
--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 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).