From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49988) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjwO0-00026R-PV for qemu-devel@nongnu.org; Fri, 22 Nov 2013 14:27:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VjwNu-0006bb-PC for qemu-devel@nongnu.org; Fri, 22 Nov 2013 14:27:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:27672) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjwNu-0006ac-FZ for qemu-devel@nongnu.org; Fri, 22 Nov 2013 14:27:22 -0500 Message-ID: <528FA2AB.2040806@redhat.com> Date: Fri, 22 Nov 2013 19:30:03 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1385072461-31317-1-git-send-email-lersek@redhat.com> <87iovkvd8t.fsf@blackfin.pond.sub.org> In-Reply-To: <87iovkvd8t.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [qemu PATCH] hw/i386/pc_sysfw: support more than one flash drive List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: edk2-devel@lists.sourceforge.net, qemu-devel@nongnu.org, crobinso@redhat.com On 11/22/13 13:21, Markus Armbruster wrote: > Laszlo Ersek writes: > >> This patch allows the user to usefully specify >> >> -drive file=img_1,if=pflash,format=raw,readonly \ >> -drive file=img_2,if=pflash,format=raw >> >> on the command line. The flash images will be mapped under 4G in their >> reverse unit order -- that is, with their base addresses progressing >> downwards, in increasing unit order. >> >> (The unit number increases with command line order if not explicitly >> specified.) >> >> This accommodates the following use case: suppose that OVMF is split in >> two parts, a writeable host file for non-volatile variable storage, and a >> read-only part for bootstrap and decompressible executable code. >> >> The binary code part would be read-only, centrally managed on the host >> system, and passed in as unit 0. The variable store would be writeable, >> VM-specific, and passed in as unit 1. >> >> 00000000ffe00000-00000000ffe1ffff (prio 0, R-): system.flash1 >> 00000000ffe20000-00000000ffffffff (prio 0, R-): system.flash0 >> >> (If the guest tries to write to the flash range that is backed by the >> read-only drive, bdrv_write() in pflash_update() will correctly deny the >> write with -EACCES, and pflash_update() won't care, which suits us well.) > > Before this patch: > > You can define as many if=pflash drives as you want. Any with non-zero > index are silently ignored. > > If you don't specify one with index=0, you get a ROM at the top of the > 32 bit address space, contents taken from -bios (default "bios.bin"). > Up to its last 128KiB are aliased at the top of the ISA address space. > > If you do specify one with index=0, you get a pflash device at the top > of the 32 bit address space, with contents from the drive, and -bios is > silently ignored. Up to its last 128KiB are copied to a ROM at the top > of the (20 bit) ISA address space. > > After this patch (please correct misunderstandings): > > Now the drives after the first unused index are silently ignored. > > If you don't specify one with index=0, no change. > > If you do, you now get N pflash devices, where N is the first unused > index. Each pflash's contents is taken from the respective drive. The > flashes are mapped at the top of the 32 bit address space in reverse > index order. -bios is silently ignored, as before. Up to the last > 128KiB of the index=0 flash are copied to a ROM at the top of the ISA > address space. > > Thus, no change for index=0. For index=1..N, we now get additional > flash devices. > > Correct? Yes. Thanks Laszlo