From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MORcF-00066p-6f for qemu-devel@nongnu.org; Wed, 08 Jul 2009 03:30:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MORcA-00066d-5K for qemu-devel@nongnu.org; Wed, 08 Jul 2009 03:30:54 -0400 Received: from [199.232.76.173] (port=44820 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MORcA-00066a-10 for qemu-devel@nongnu.org; Wed, 08 Jul 2009 03:30:50 -0400 Received: from mx20.gnu.org ([199.232.41.8]:53013) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MORc9-0003UD-Db for qemu-devel@nongnu.org; Wed, 08 Jul 2009 03:30:49 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MORc7-0008G1-Vl for qemu-devel@nongnu.org; Wed, 08 Jul 2009 03:30:48 -0400 Message-ID: <4A544AD2.9030504@redhat.com> Date: Wed, 08 Jul 2009 09:29:22 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qcow2: Fix L1 table memory allocation References: <1246982982-11615-1-git-send-email-kwolf@redhat.com> <4A537735.9060904@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: Avi Kivity , qemu-devel@nongnu.org malc schrieb: > On Tue, 7 Jul 2009, Avi Kivity wrote: > >> On 07/07/2009 07:09 PM, Kevin Wolf wrote: >>> Contrary to what one could expect, the size of L1 tables is not cluster >>> aligned. So as we're writing whole sectors now instead of single entries, >>> we need to ensure that the L1 table in memory is large enough; otherwise >>> write would access memory after the end of the L1 table. >>> >>> >>> new_l1_size2 = sizeof(uint64_t) * new_l1_size; >>> - new_l1_table = qemu_mallocz(new_l1_size2); >>> + new_l1_table = qemu_mallocz(align_offset(new_l1_size2, 512)); >>> memcpy(new_l1_table, s->l1_table, s->l1_size * sizeof(uint64_t)); >>> >> Unrelated note: using qemu_memalign() here would reduce the copying for >> cache=none. >> > > Another unrelated note, qemu_memalign(and by extension qemu_vmalloc) > is NULL happy. And FWIW 487414f1cbd638beb0227c7da71fe7b8a821e155 > removed NULL checks for qemu_memalgn and after that new code was added > that doesn't check for NULLs either (for instance e3f4e2a4 which has > bitten me). Good to know that there still is an alternative that isn't broken. Another good reason to switch to qemu_memalign. Kevin