From: WANG Xuerui <kernel@xen0n.name>
To: Paolo Bonzini <pbonzini@redhat.com>, Huacai Chen <chenhuacai@kernel.org>
Cc: Tianrui Zhao <zhaotianrui@loongson.cn>,
Bibo Mao <maobibo@loongson.cn>,
kvm@vger.kernel.org, loongarch@lists.linux.dev,
linux-kernel@vger.kernel.org, WANG Xuerui <git@xen0n.name>
Subject: [PATCH for-6.8 v3 0/3] KVM: LoongArch: Fix wrong CPUCFG ID handling
Date: Fri, 16 Feb 2024 16:58:19 +0800 [thread overview]
Message-ID: <20240216085822.3032984-1-kernel@xen0n.name> (raw)
From: WANG Xuerui <git@xen0n.name>
Hi,
While trying to add loongarch to the Rust kvm-bindings crate, I
accidentally discovered faulty logic in the handling of CPUCFG IDs
("leaves" for those more familiar with x86), that could result in
incorrectly accepting every possible int for the ID; fortunately it is
6.8 material that hasn't seen a release yet, so a fix is possible.
The first patch contains the fix, while the rest are general
drive-by refactoring and comment cleanups.
Although it is currently the Chinese holiday season, Huacai told me
over IM that he's able to test the series and handle the upstreaming, so
going through the loongarch tree seems to be the way forward for the
series.
v3 changes:
- Fixed the validation by accepting every CPUCFG IDs from 0 to 20
inclusive, instead of only 2; this was a misunderstanding of mine
regarding the userland. (currently the only known user, the QEMU
target/loongarch KVM code, expects to be able to set all these 21
CPUCFG leaves, even though 7~15 are undefined according to the
LoongArch reference manual.) This also had the effect of squashing the
first 2 patches.
- Made the _kvm_get_cpucfg_mask return a mask in all valid cases,
allowing the mask check to be lifted out of the CPUCFG2 case.
- Swapped the "LoongArch:" and "KVM:" tags because right now the patches
are likely to reach mainline through the loongarch tree, and having
the "LoongArch:" prefix first is the convention here.
v2 changes:
- Squashed the v1 patches 4 and 5 according to Huacai's review
- Reworded comments according to Huacai's suggestion
- Use WARN_ON_ONCE (instead of BUG) to replace unreachable() for not
crashing the kernel (per checkpatch.pl suggestion)
WANG Xuerui (3):
LoongArch: KVM: Fix input validation of _kvm_get_cpucfg and
kvm_check_cpucfg
LoongArch: KVM: Rename _kvm_get_cpucfg to _kvm_get_cpucfg_mask
LoongArch: KVM: Streamline kvm_check_cpucfg and improve comments
arch/loongarch/kvm/vcpu.c | 81 ++++++++++++++++++---------------------
1 file changed, 38 insertions(+), 43 deletions(-)
--
2.43.0
next reply other threads:[~2024-02-16 8:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-16 8:58 WANG Xuerui [this message]
2024-02-16 8:58 ` [PATCH for-6.8 v3 1/3] LoongArch: KVM: Fix input validation of _kvm_get_cpucfg and kvm_check_cpucfg WANG Xuerui
2024-02-17 3:03 ` maobibo
2024-02-22 9:45 ` WANG Xuerui
2024-02-22 10:22 ` maobibo
2024-02-22 10:39 ` WANG Xuerui
2024-02-16 8:58 ` [PATCH for-6.8 v3 2/3] LoongArch: KVM: Rename _kvm_get_cpucfg to _kvm_get_cpucfg_mask WANG Xuerui
2024-02-16 8:58 ` [PATCH for-6.8 v3 3/3] LoongArch: KVM: Streamline kvm_check_cpucfg and improve comments WANG Xuerui
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=20240216085822.3032984-1-kernel@xen0n.name \
--to=kernel@xen0n.name \
--cc=chenhuacai@kernel.org \
--cc=git@xen0n.name \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=maobibo@loongson.cn \
--cc=pbonzini@redhat.com \
--cc=zhaotianrui@loongson.cn \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).