From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uoobr-0003z7-KN for qemu-devel@nongnu.org; Tue, 18 Jun 2013 01:37:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uoobq-0002uP-Me for qemu-devel@nongnu.org; Tue, 18 Jun 2013 01:37:39 -0400 Message-ID: <51BFF21A.7050008@redhat.com> Date: Tue, 18 Jun 2013 07:37:30 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1371487106-17194-1-git-send-email-anthony.perard@citrix.com> <51BFCDA1.8040507@msgid.tls.msk.ru> In-Reply-To: <51BFCDA1.8040507@msgid.tls.msk.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-trivial] [PATCH] qxl: Fix QXLRam initialisation. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev Cc: Anthony PERARD , qemu-trivial@nongnu.org, Alon Levy , QEMU-devel , qemu-stable Hi, >> If memory is set to 0xc2c2.., it leads to a spice-critical error when >> trying to start qxl. > But maybe instead of doing it this way, we should just memset the > whole thing to 0, to avoid similar bugs in the future? Are there > any arches out there which have cpu_to_le32(0) != 0 ? On qemu + kvm guest memory (including pci device memory where this lives in) _is_ zero initialized. IIRC xen has a debug mode where it fills memory with non-zero values instead, for debugging / testing purposes, and this is where things blow up. So while the fix is clearly correct, the patch isn't as critical as it initially looks like. Reviewed-by: Gerd Hoffmann cheers, Gerd