On Tue, 5 Apr 2022 at 14:07, Daniel Henrique Barboza
<danielhb...@gmail.com> wrote:
>
> There is a lot of Valgrind warnings about conditional jump depending on
> unintialized values like this one (taken from a pSeries guest):
>
> Conditional jump or move depends on uninitialised value(s)
> at 0xB011DC: kvmppc_enable_cap_large_decr (kvm.c:2544)
> by 0x92F28F: cap_large_decr_cpu_apply (spapr_caps.c:523)
> by 0x930C37: spapr_caps_cpu_apply (spapr_caps.c:921)
> by 0x955D3B: spapr_reset_vcpu (spapr_cpu_core.c:73)
> (...)
> Uninitialised value was created by a stack allocation
> at 0xB01150: kvmppc_enable_cap_large_decr (kvm.c:2538)
>
> In this case, the alleged unintialized value is the 'lpcr' variable that
> is written by kvm_get_one_reg() and then used in an if clause:
>
> int kvmppc_enable_cap_large_decr(PowerPCCPU *cpu, int enable)
> {
> CPUState *cs = CPU(cpu);
> uint64_t lpcr;
>
> kvm_get_one_reg(cs, KVM_REG_PPC_LPCR_64, &lpcr);
> /* Do we need to modify the LPCR? */
> if (!!(lpcr & LPCR_LD) != !!enable) { <---- Valgrind warns here
> (...)
>
> A quick fix is to init the variable that kvm_get_one_reg() is going to
> write ('lpcr' in the example above). Another idea is to convince
> Valgrind that kvm_get_one_reg() inits the 'void *target' memory in case
> the ioctl() is successful. This will put some boilerplate in the
> function but it will bring benefit for its other callers.
Doesn't Valgrind have a way of modelling ioctls where it
knows what data is read and written ? In general
ioctl-using programs don't need to have special case
"I am running under valgrind" handling, so this seems to
me like valgrind is missing support for this particular ioctl.
More generally, how much use is running QEMU with KVM enabled
under valgrind anyway? Valgrind has no way of knowing about
writes to memory that the guest vCPUs do...
thanks
-- PMM
