From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:51157) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1go8X6-0008Dl-KQ for qemu-devel@nongnu.org; Mon, 28 Jan 2019 10:09:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1go8SD-0005pY-C5 for qemu-devel@nongnu.org; Mon, 28 Jan 2019 10:04:11 -0500 References: <87y378n5iy.fsf@dusky.pond.sub.org> <20190128124027.776wwcqrckalvr7x@sirius.home.kraxel.org> <5daf9f5e-cbda-8642-f4f6-46939fe223d1@redhat.com> From: Laszlo Ersek Message-ID: Date: Mon, 28 Jan 2019 16:03:38 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] Configuring pflash devices for OVMF firmware List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Gerd Hoffmann , Markus Armbruster , Libvirt , Peter Krempa , QEMU Developers , Qemu-block , Ard Biesheuvel On 01/28/19 15:58, Peter Maydell wrote: > On Mon, 28 Jan 2019 at 14:56, Laszlo Ersek wrote: >> Regarding OVMF, I kept the flash driver intentionally in the dark about >> split vs. unified pflash, so OVMF will not care, as long as the same >> GPAs behave the same as before. >> >> Regarding ArmVirtQemu, I'm not so sure. It think it already depends on >> two separate pflash chips, through the DTB that QEMU exposes. So >> unifying the chips (albeit with multiple regions) might actually confuse >> the firmware. > > "virt" is a funny case because there is no underlying hardware > that we're trying to match. So it is whatever we say it is > and we've said it's two separate pflash chips. We don't need > to change that I think. (IIRC this is derived partly from > OVMF usecase requirements and partly from the vexpress devboards > having 2 flash chips.) That sounds great, but in that case, would the work be justified in practice, to introduce single-ship-with-multiple-regions, if only x86 put it to use (for OVMF), but arm/aarch64 "virt" would have to stick with the current layout? Thanks Laszlo