Message ID | 20240216085822.3032984-2-kernel@xen0n.name (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | KVM: LoongArch: Fix wrong CPUCFG ID handling | expand |
Hi Xuerui, Good catch, and thank for your patch. On 2024/2/16 下午4:58, WANG Xuerui wrote: > From: WANG Xuerui <git@xen0n.name> > > The range check for the CPUCFG ID is wrong (should have been a || > instead of &&); it is conceptually simpler to just express the check > as another case of the switch statement on the ID. As it turns out to be > the case, the userland (currently only the QEMU/KVM target code) expects > to set CPUCFG IDs 0 to 20 inclusive, but only CPUCFG2 values are being > validated. > > Furthermore, the juggling of the temp return value is unnecessary, > because it is semantically equivalent and more readable to just > return at every switch case's end. This is done too to avoid potential > bugs in the future related to the unwanted complexity. > > Also, the return value of _kvm_get_cpucfg is meant to be checked, but > this was not done, so bad CPUCFG IDs wrongly fall back to the default > case and 0 is incorrectly returned; check the return value to fix the > UAPI behavior. > > While at it, also remove the redundant range check in kvm_check_cpucfg, > because out-of-range CPUCFG IDs are already rejected by the -EINVAL > as returned by _kvm_get_cpucfg. > > Fixes: db1ecca22edf ("LoongArch: KVM: Add LSX (128bit SIMD) support") > Signed-off-by: WANG Xuerui <git@xen0n.name> > --- > arch/loongarch/kvm/vcpu.c | 33 +++++++++++++++------------------ > 1 file changed, 15 insertions(+), 18 deletions(-) > > diff --git a/arch/loongarch/kvm/vcpu.c b/arch/loongarch/kvm/vcpu.c > index 27701991886d..56da0881fc94 100644 > --- a/arch/loongarch/kvm/vcpu.c > +++ b/arch/loongarch/kvm/vcpu.c > @@ -300,11 +300,6 @@ static int _kvm_setcsr(struct kvm_vcpu *vcpu, unsigned int id, u64 val) > > static int _kvm_get_cpucfg(int id, u64 *v) > { > - int ret = 0; > - > - if (id < 0 && id >= KVM_MAX_CPUCFG_REGS) > - return -EINVAL; > - yes, it had better be removed since the same thing is done in function kvm_check_cpucfg(). > switch (id) { > case 2: > /* Return CPUCFG2 features which have been supported by KVM */ > @@ -324,31 +319,33 @@ static int _kvm_get_cpucfg(int id, u64 *v) > if (cpu_has_lasx) > *v |= CPUCFG2_LASX; > > - break; > + return 0; > + case 0 ... 1: > + case 3 ... KVM_MAX_CPUCFG_REGS - 1: > + /* no restrictions on other CPUCFG IDs' values */ > + *v = U64_MAX; > + return 0; how about something like this? default: /* no restrictions on other CPUCFG IDs' values */ *v = U64_MAX; return 0; Regards Bibo Mao > default: > - ret = -EINVAL; > - break; > + return -EINVAL; > } > - return ret; > } > > static int kvm_check_cpucfg(int id, u64 val) > { > - u64 mask; > - int ret = 0; > - > - if (id < 0 && id >= KVM_MAX_CPUCFG_REGS) > - return -EINVAL; > + u64 mask = 0; > + int ret; > > - if (_kvm_get_cpucfg(id, &mask)) > + ret = _kvm_get_cpucfg(id, &mask); > + if (ret) > return ret; > > + if (val & ~mask) > + /* Unsupported features should not be set */ > + return -EINVAL; > + > switch (id) { > case 2: > /* CPUCFG2 features checking */ > - if (val & ~mask) > - /* The unsupported features should not be set */ > - ret = -EINVAL; > else if (!(val & CPUCFG2_LLFTP)) > /* The LLFTP must be set, as guest must has a constant timer */ > ret = -EINVAL; >
Hi, On 2/17/24 11:03, maobibo wrote: > Hi Xuerui, > > Good catch, and thank for your patch. > > On 2024/2/16 下午4:58, WANG Xuerui wrote: >> [snip] >> @@ -324,31 +319,33 @@ static int _kvm_get_cpucfg(int id, u64 *v) >> if (cpu_has_lasx) >> *v |= CPUCFG2_LASX; >> - break; >> + return 0; >> + case 0 ... 1: >> + case 3 ... KVM_MAX_CPUCFG_REGS - 1: >> + /* no restrictions on other CPUCFG IDs' values */ >> + *v = U64_MAX; >> + return 0; > how about something like this? > default: > /* no restrictions on other CPUCFG IDs' values */ > *v = U64_MAX; > return 0; I don't think this version correctly expresses the intent. Note that the CPUCFG ID range check is squashed into the switch as well, so one switch conveniently expresses the three intended cases at once: * the special treatment of CPUCFG2, * all-allow rules for other in-range CPUCFG IDs, and * rejection for out-of-range IDs. Yet the suggestion here is conflating the latter two cases, with the effect of allowing every ID that's not 2 to take any value (as expressed by the U64_MAX mask), and *removing the range check* (because no return path returns -EINVAL with this change). So I'd like to stick to the current version, but thanks anyway for your kind review and suggestion.
On 2024/2/22 下午5:45, WANG Xuerui wrote: > Hi, > > On 2/17/24 11:03, maobibo wrote: >> Hi Xuerui, >> >> Good catch, and thank for your patch. >> >> On 2024/2/16 下午4:58, WANG Xuerui wrote: >>> [snip] >>> @@ -324,31 +319,33 @@ static int _kvm_get_cpucfg(int id, u64 *v) >>> if (cpu_has_lasx) >>> *v |= CPUCFG2_LASX; >>> - break; >>> + return 0; >>> + case 0 ... 1: >>> + case 3 ... KVM_MAX_CPUCFG_REGS - 1: >>> + /* no restrictions on other CPUCFG IDs' values */ >>> + *v = U64_MAX; >>> + return 0; >> how about something like this? >> default: >> /* no restrictions on other CPUCFG IDs' values */ >> *v = U64_MAX; >> return 0; > > I don't think this version correctly expresses the intent. Note that the > CPUCFG ID range check is squashed into the switch as well, so one switch > conveniently expresses the three intended cases at once: > > * the special treatment of CPUCFG2, + case 0 ... 1: + case 3 ... KVM_MAX_CPUCFG_REGS - 1: + /* no restrictions on other CPUCFG IDs' values */ + *v = U64_MAX; + return 0; cpucfg6 checking will be added for PMU support soon. So it will be case 6: do something check for cpucfg6 return mask; case 0 ... 1: case 3 ... 5: case 7 ... KVM_MAX_CPUCFG_REGS - 1: *v = U64_MAX; return 0; If you think it is reasonable to add these separate "case" sentences, I have no objection. > * all-allow rules for other in-range CPUCFG IDs, and > * rejection for out-of-range IDs. static int kvm_check_cpucfg(int id, u64 val) { - u64 mask; - int ret = 0; - - if (id < 0 && id >= KVM_MAX_CPUCFG_REGS) - return -EINVAL; you can modify && with ||, like this: if (id < 0 || id >= KVM_MAX_CPUCFG_REGS) return -EINVAL; + u64 mask = 0; + int ret; Regards Bibo Mao > > Yet the suggestion here is conflating the latter two cases, with the > effect of allowing every ID that's not 2 to take any value (as expressed > by the U64_MAX mask), and *removing the range check* (because no return > path returns -EINVAL with this change). > > So I'd like to stick to the current version, but thanks anyway for your > kind review and suggestion. >
On 2/22/24 18:22, maobibo wrote: > > > On 2024/2/22 下午5:45, WANG Xuerui wrote: >> Hi, >> >> On 2/17/24 11:03, maobibo wrote: >>> Hi Xuerui, >>> >>> Good catch, and thank for your patch. >>> >>> On 2024/2/16 下午4:58, WANG Xuerui wrote: >>>> [snip] >>>> @@ -324,31 +319,33 @@ static int _kvm_get_cpucfg(int id, u64 *v) >>>> if (cpu_has_lasx) >>>> *v |= CPUCFG2_LASX; >>>> - break; >>>> + return 0; >>>> + case 0 ... 1: >>>> + case 3 ... KVM_MAX_CPUCFG_REGS - 1: >>>> + /* no restrictions on other CPUCFG IDs' values */ >>>> + *v = U64_MAX; >>>> + return 0; >>> how about something like this? >>> default: >>> /* no restrictions on other CPUCFG IDs' values */ >>> *v = U64_MAX; >>> return 0; >> >> I don't think this version correctly expresses the intent. Note that >> the CPUCFG ID range check is squashed into the switch as well, so one >> switch conveniently expresses the three intended cases at once: >> >> * the special treatment of CPUCFG2, > + case 0 ... 1: > + case 3 ... KVM_MAX_CPUCFG_REGS - 1: > + /* no restrictions on other CPUCFG IDs' values */ > + *v = U64_MAX; > + return 0; > cpucfg6 checking will be added for PMU support soon. So it will be > case 6: > do something check for cpucfg6 > return mask; > case 0 ... 1: > case 3 ... 5: > case 7 ... KVM_MAX_CPUCFG_REGS - 1: > *v = U64_MAX; > return 0; > > If you think it is reasonable to add these separate "case" sentences, I > have no objection. >> * all-allow rules for other in-range CPUCFG IDs, and >> * rejection for out-of-range IDs. > static int kvm_check_cpucfg(int id, u64 val) > { > - u64 mask; > - int ret = 0; > - > - if (id < 0 && id >= KVM_MAX_CPUCFG_REGS) > - return -EINVAL; > you can modify && with ||, like this: > if (id < 0 || id >= KVM_MAX_CPUCFG_REGS) > return -EINVAL; Yes I know. Personally I don't find the "three cases" that annoying, but I agree with you that it can be mildly frustrating if one case addition would split the ranges even more. Given I'd like to also change the U64_MAX into U32_MAX (CPUCFG data is specified to be 32-bit wide), I'll send a v4 that keeps the "if" branch to make more people happy (Huacai privately also expressed preference for minimizing changes to the overall code shape). Thanks for your suggestion.
diff --git a/arch/loongarch/kvm/vcpu.c b/arch/loongarch/kvm/vcpu.c index 27701991886d..56da0881fc94 100644 --- a/arch/loongarch/kvm/vcpu.c +++ b/arch/loongarch/kvm/vcpu.c @@ -300,11 +300,6 @@ static int _kvm_setcsr(struct kvm_vcpu *vcpu, unsigned int id, u64 val) static int _kvm_get_cpucfg(int id, u64 *v) { - int ret = 0; - - if (id < 0 && id >= KVM_MAX_CPUCFG_REGS) - return -EINVAL; - switch (id) { case 2: /* Return CPUCFG2 features which have been supported by KVM */ @@ -324,31 +319,33 @@ static int _kvm_get_cpucfg(int id, u64 *v) if (cpu_has_lasx) *v |= CPUCFG2_LASX; - break; + return 0; + case 0 ... 1: + case 3 ... KVM_MAX_CPUCFG_REGS - 1: + /* no restrictions on other CPUCFG IDs' values */ + *v = U64_MAX; + return 0; default: - ret = -EINVAL; - break; + return -EINVAL; } - return ret; } static int kvm_check_cpucfg(int id, u64 val) { - u64 mask; - int ret = 0; - - if (id < 0 && id >= KVM_MAX_CPUCFG_REGS) - return -EINVAL; + u64 mask = 0; + int ret; - if (_kvm_get_cpucfg(id, &mask)) + ret = _kvm_get_cpucfg(id, &mask); + if (ret) return ret; + if (val & ~mask) + /* Unsupported features should not be set */ + return -EINVAL; + switch (id) { case 2: /* CPUCFG2 features checking */ - if (val & ~mask) - /* The unsupported features should not be set */ - ret = -EINVAL; else if (!(val & CPUCFG2_LLFTP)) /* The LLFTP must be set, as guest must has a constant timer */ ret = -EINVAL;