Re: [PATCH v2 2/4] target/ppc: init 'lpcr' in kvmppc_enable_cap_large_decr()

[David Gibson]

On Thu, Mar 31, 2022 at 02:17:42PM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 3/30/22 22:25, David Gibson wrote:
> > On Wed, Mar 30, 2022 at 09:17:15PM -0300, Daniel Henrique Barboza wrote:
> > > 'lpcr' is used as an input of kvm_get_one_reg(). Valgrind doesn't
> > > understand that and it returns warnings as such for this function:
> > > 
> > > ==55240== Thread 1:
> > > ==55240== Conditional jump or move depends on uninitialised value(s)
> > > ==55240==    at 0xB011E4: kvmppc_enable_cap_large_decr (kvm.c:2546)
> > > ==55240==    by 0x92F28F: cap_large_decr_cpu_apply (spapr_caps.c:523)
> > > ==55240==    by 0x930C37: spapr_caps_cpu_apply (spapr_caps.c:921)
> > > ==55240==    by 0x955D3B: spapr_reset_vcpu (spapr_cpu_core.c:73)
> > > ==55240==    by 0x95612B: spapr_cpu_core_reset (spapr_cpu_core.c:209)
> > > ==55240==    by 0x95619B: spapr_cpu_core_reset_handler 
> > > (spapr_cpu_core.c:218)
> > > ==55240==    by 0xD3605F: qemu_devices_reset (reset.c:69)
> > > ==55240==    by 0x92112B: spapr_machine_reset (spapr.c:1641)
> > > ==55240==    by 0x4FBD63: qemu_system_reset (runstate.c:444)
> > > ==55240==    by 0x62812B: qdev_machine_creation_done (machine.c:1247)
> > > ==55240==    by 0x5064C3: qemu_machine_creation_done (vl.c:2725)
> > > ==55240==    by 0x5065DF: qmp_x_exit_preconfig (vl.c:2748)
> > > ==55240==  Uninitialised value was created by a stack allocation
> > > ==55240==    at 0xB01158: kvmppc_enable_cap_large_decr (kvm.c:2540)
> > > 
> > > Init 'lpcr' to avoid this warning.
> > 
> > Hmm... this is seeming a bit like whack-a-mole.  Could we instead use
> > one of the valgrind hinting mechanisms to inform it that
> > kvm_get_one_reg() writes the variable at *target?
> 
> I didn't find a way of doing that looking in the memcheck helpers
> (https://valgrind.org/docs/manual/mc-manual.html section 4.7). That would be a
> good way of solving this warning because we would put stuff inside a specific
> function X and all callers of X would be covered by it.
> 
> What I did find instead is a memcheck macro called VALGRIND_MAKE_MEM_DEFINED 
> that
> tells Valgrind that the var was initialized.

I think that's the one I was thinking of.

> This patch would then be something as follows:
> 
> 
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index dc93b99189..b0e22fa283 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -56,6 +56,10 @@
>  #define DEBUG_RETURN_GUEST 0
>  #define DEBUG_RETURN_GDB   1
> +#ifdef CONFIG_VALGRIND_H
> +#include <valgrind/memcheck.h>
> +#endif
> +
>  const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
>      KVM_CAP_LAST_INFO
>  };
> @@ -2539,6 +2543,10 @@ int kvmppc_enable_cap_large_decr(PowerPCCPU *cpu, int 
> enable)
>      CPUState *cs = CPU(cpu);
>      uint64_t lpcr;
> +#ifdef CONFIG_VALGRIND_H
> +    VALGRIND_MAKE_MEM_DEFINED(lpcr, sizeof(uint64_t));
> +#endif
> +
>      kvm_get_one_reg(cs, KVM_REG_PPC_LPCR_64, &lpcr);
>      /* Do we need to modify the LPCR? */

The macro call should only go after the get_one_reg, of course.

> CONFIG_VALGRIND_H needs 'valgrind-devel´ installed.

Right.. better would probably be to make a wrapper macro defined as a
no-op in the !CONFIG_VALGRIND_H case, so you don't need the ifdefs at
the point you use it.
> 
> I agree that this "Valgrind is complaining about variable initialization" is 
> a whack-a-mole
> situation that will keep happening in the future if we keep adding this same 
> code pattern
> (passing as reference an uninitialized var). For now, given that we have only 
> 4 instances
> to fix it in ppc code (as far as I'm aware of), and we don't have a better 
> way of telling
> Valgrind that we know what we're doing, I think we're better of
> initializing these vars.

Hmm... still feels like it would be better to put the
MAKE_MEM_DEFINED inside kvm_get_one_reg().  I think the difficulty
with that is that it handles both 32-bit and 64-bit registers and I'm
not sure if there's an easy way to work out exactly how many bits
*have* been initialized.

> 
> 
> Thanks,
> 
> 
> Daniel
> 
> 
> 
> > 
> > > Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> > > Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
> > > ---
> > >   target/ppc/kvm.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> > > index 858866ecd4..42814e1b97 100644
> > > --- a/target/ppc/kvm.c
> > > +++ b/target/ppc/kvm.c
> > > @@ -2538,7 +2538,7 @@ int kvmppc_get_cap_large_decr(void)
> > >   int kvmppc_enable_cap_large_decr(PowerPCCPU *cpu, int enable)
> > >   {
> > >       CPUState *cs = CPU(cpu);
> > > -    uint64_t lpcr;
> > > +    uint64_t lpcr = 0;
> > >       kvm_get_one_reg(cs, KVM_REG_PPC_LPCR_64, &lpcr);
> > >       /* Do we need to modify the LPCR? */
> > 
> 

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

signature.asc
Description: PGP signature