On Sat, 27 Jul 2024 at 02:36, Atish Kumar Patra <ati...@rivosinc.com> wrote: > > On Thu, Jul 25, 2024 at 10:12 PM Alistair Francis <alistai...@gmail.com> > wrote: > > > > On Wed, Jul 24, 2024 at 6:33 PM Atish Patra <ati...@rivosinc.com> wrote: > > > > > > Coverity complained about the possible out-of-bounds access with > > > counter_virt/counter_virt_prev because these two arrays are > > > accessed with privilege mode. However, these two arrays are accessed > > > only when virt is enabled. Thus, the privilege mode can't be M mode. > > > > > > Add the asserts anyways to detect any wrong usage of these arrays > > > in the future. > > > > > > Suggested-by: Peter Maydell <peter.mayd...@linaro.org> > > > Signed-off-by: Atish Patra <ati...@rivosinc.com> > > > > Fixes: Coverity CID 1558459 > > Fixes: Coverity CID 1558462 > > > > I think one of the Coverity issues was about the get_field issue in > the other thread? > This doesn't necessarily fix the coverity issue also as the issue > reported is a false positive. > But I don't mind citing the coverity issues as it is reported by that. > > Is there a link to both coverity issues to know which issue describes > the out-of-bound access one ?
You can't do deep links into the Coverity Scan UI, but if you want to ask for an account at https://scan.coverity.com/projects/qemu we generally give them to any developer who asks. In this case 1558459 is complaining about the call to riscv_pmu_update_fixed_ctrs(env, newpriv, virt_en); in riscv_cpu_set_mode(), and 1558462 is complaining about the call to riscv_cpu_set_mode(env, PRV_M, virt) in riscv_cpu_do_interrupt(). So it's basically reported the same problem twice, at different levels in the callstack. I don't know why it's done that, but it's not that uncommon that the same problem gets detected several ways. The complaints about get_field/set_field were different: those were 1558461, 1558463. I've already marked those as false-positives in the UI. (Generally my practice is that where we think there's no point in making a change to QEMU's code I mark the issue as a false-positive; where we think it is reasonable to make a change to QEMU's code (e.g. to aid the human reader or where we think an assert() is useful) I leave it marked as "bug" to indicate we want to change something, even if Coverity's analysis is wrong and it's a can't-happen case.) thanks -- PMM
