From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NlXTe-0001C7-Jj for qemu-devel@nongnu.org; Sat, 27 Feb 2010 19:57:46 -0500 Received: from [199.232.76.173] (port=39291 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NlXTe-0001Bv-9L for qemu-devel@nongnu.org; Sat, 27 Feb 2010 19:57:46 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NlXTd-0004Us-IS for qemu-devel@nongnu.org; Sat, 27 Feb 2010 19:57:46 -0500 Received: from mx20.gnu.org ([199.232.41.8]:56335) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NlXTd-0004Uo-CW for qemu-devel@nongnu.org; Sat, 27 Feb 2010 19:57:45 -0500 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NlXTc-0003rG-FT for qemu-devel@nongnu.org; Sat, 27 Feb 2010 19:57:44 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] pc: madvise(MADV_DONTNEED) memory on reset Date: Sun, 28 Feb 2010 00:57:40 +0000 References: <1267038612-21581-1-git-send-email-aliguori@us.ibm.com> <4B85A2C7.6040406@codemonkey.ws> In-Reply-To: <4B85A2C7.6040406@codemonkey.ws> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201002280057.41164.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Blue Swirl > > I think it would be much cleaner to make the madvise() calls from > > exec.c, now you are duplicating some of the functionality there. The > > calls could be controlled by a global variable (set only in pc.c) so > > non-PC architectures would not be disturbed. > > One thing we could do (that I think has other uses) is to add a context > parameter to qemu_ram_alloc(). We could start with a simple flag of > something like QRAM_RAM and QRAM_ROM. QRAM_RAM would get automatically > madvise()'d on reset. > > But that said, does anyone know of an architecture where this type of > reset would be a problem? Would it be a problem on sparc? I think it's simplest to just say that qemu_system_reset is a full hard reset. We already reload ROM images, etc. Paul