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.
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? */
CONFIG_VALGRIND_H needs 'valgrind-devel´ installed.
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.
Thanks,
Daniel
Reviewed-by: Philippe Mathieu-Daudé <f4...@amsat.org>
Signed-off-by: Daniel Henrique Barboza <danielhb...@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? */
