From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55154) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3lEN-0006I4-LP for qemu-devel@nongnu.org; Tue, 21 Aug 2012 05:58:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T3lEH-0002KX-TS for qemu-devel@nongnu.org; Tue, 21 Aug 2012 05:58:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26008) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3lEH-0002KR-K7 for qemu-devel@nongnu.org; Tue, 21 Aug 2012 05:58:33 -0400 Message-ID: <50335BC3.7030607@redhat.com> Date: Tue, 21 Aug 2012 12:58:27 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1344604305-25312-1-git-send-email-borntraeger@de.ibm.com> <50334EEC.20501@de.ibm.com> In-Reply-To: <50334EEC.20501@de.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC/PATCH] qemu: Use valgrind annotations to mark kvm guest memory as defined List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Borntraeger Cc: Anthony Liguori , Marcelo Tosatti , qemu-devel@nongnu.org On 08/21/2012 12:03 PM, Christian Borntraeger wrote: > On 10/08/12 15:11, Christian Borntraeger wrote: >> valgrind with kvm produces a big amount of false positives regarding >> "Conditional jump or move depends on uninitialised value(s)". This >> happens because the guest memory is allocated with qemu_vmalloc which >> boils down posix_memalign etc. This function is (correctly) considered >> by valgrind as returning undefined memory. >> >> Since valgrind is based on jitting code, it will not be able to see >> changes made by the guest to guest memory if this is done by KVM_RUN, >> thus keeping most of the guest memory undefined. >> >> Now lots of places in qemu will then use guest memory to change behaviour. >> To avoid the flood of these messages, lets declare the whole guest >> memory as defined. This will reduce the noise and allows us to see real >> problems. >> >> In the future we might want to make this conditional, since there >> is actually something that we can use those false positives for: >> These messages will point to code that depends on guest memory, so >> we can use these backtraces to actually make an audit that is focussed >> only at those code places. For normal development we dont want to >> see those messages, though. > > > Any opinion about this patch? Missed it, sorry. Now applied to uq/master, thanks. -- error compiling committee.c: too many arguments to function