From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzMDh-00037W-2P for qemu-devel@nongnu.org; Mon, 01 Jun 2015 05:41:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YzMDd-000720-QK for qemu-devel@nongnu.org; Mon, 01 Jun 2015 05:41:21 -0400 Received: from mail-wg0-x22a.google.com ([2a00:1450:400c:c00::22a]:34232) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzMDd-00071w-JY for qemu-devel@nongnu.org; Mon, 01 Jun 2015 05:41:17 -0400 Received: by wgv5 with SMTP id 5so109136732wgv.1 for ; Mon, 01 Jun 2015 02:41:17 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <556C28B6.5050803@redhat.com> Date: Mon, 01 Jun 2015 11:41:10 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <2816EEF2-0256-4B49-8811-74EFB3016CD4@livius.net> <20150529111118.7f116572@nial.brq.redhat.com> <7A249492-B5F2-46D5-92A2-12BB30202C5F@livius.net> <84953DC4-7936-4C86-B442-BAFB325E540D@livius.net> <556C078C.1070709@redhat.com> <789EE1D0-A6B3-4F50-92A8-E8EF453634BA@livius.net> <556C1D70.5000304@redhat.com> <770D59BE-11DE-4334-8933-05A6183CE93F@livius.net> In-Reply-To: <770D59BE-11DE-4334-8933-05A6183CE93F@livius.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] extensions to the -m memory option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Liviu Ionescu Cc: Peter Maydell , Peter Crosthwaite , QEMU Developers , Igor Mammedov On 01/06/2015 11:23, Liviu Ionescu wrote: > however, the desired behaviour is > > - the -pflash specifies a file path, no need for size > - when emulation starts, if -pflash is used and the file exists, its content is loaded as initial flash content > - when emulation ends, if -pflash is used, the flash content is saved to this file > - if the gdb server is used, it must allow for some parts of the flash to be overwritten by GDB, for example the bootloader is located either in low or high memory, and the rest of the flash is reprogrammed by the debugger with each session, the bootloader (and the rest of the flash) remaining persistent between sessions. > > does the existing -pflash implementation matches this expected use case? Yes, entirely. Saving flash content can be avoided by using "-drive if=pflash,snapshot=on,file=...". So it looks like you have a use for both -kernel (ELF) and -pflash (raw image). Paolo