From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vlgsg-0002yo-5A for qemu-devel@nongnu.org; Wed, 27 Nov 2013 10:18:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vlgsa-0000E6-4c for qemu-devel@nongnu.org; Wed, 27 Nov 2013 10:18:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50740) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlgsZ-0000Dy-T8 for qemu-devel@nongnu.org; Wed, 27 Nov 2013 10:18:16 -0500 Message-ID: <52960D2C.4020103@redhat.com> Date: Wed, 27 Nov 2013 16:18:04 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1385072461-31317-1-git-send-email-lersek@redhat.com> <87iovkvd8t.fsf@blackfin.pond.sub.org> <528FA2AB.2040806@redhat.com> <871u244ic6.fsf@blackfin.pond.sub.org> <5293A8CF.1000602@redhat.com> <87y54bgx1e.fsf@blackfin.pond.sub.org> <5294A301.9050101@redhat.com> <87iove7xzm.fsf@blackfin.pond.sub.org> <5295FB20.1000007@redhat.com> <8761rd52fc.fsf@blackfin.pond.sub.org> In-Reply-To: <8761rd52fc.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" , Jordan Justen , qemu-devel , Cole Robinson On 11/27/13 15:45, Markus Armbruster wrote: > Laszlo Ersek writes: > >> On 11/27/13 14:52, Markus Armbruster wrote: >>> Jordan Justen writes: >>> >>>> On Tue, Nov 26, 2013 at 5:32 AM, Laszlo Ersek wrote: >>>>> On 11/26/13 13:36, Markus Armbruster wrote: >>>>> >>>>>> Your stated purpose for multiple -pflash: >>>>>> >>>>>> 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. >>>>>> >>>>>> Such a split between writable part and read-only part makes sense to me. >>>>>> How is it done in physical hardware? Single device with configurable >>>>>> write-protect, or two separate devices? >>>>> >>>>> (Jordan could help more.) >>>>> >>>>> Likely one device that's fully writeable. >>>> >>>> Most parts will have a dedicated read-only line. >>>> >>>> Many devices have 'block-locking' that will make some subset of blocks >>>> read-only until a reset. >>>> >>>> In addition to this, many chipsets will allow flash writes to be >>>> protected by triggering SMM when a flash write occurs. >>>> >>>> Using multiple chips are less common due to cost, but this is not a >>>> factor for QEMU. :) >>> >>> Should we stick to what real hardware does? Single device, perhaps with >>> block locking. >> >> I can't back a single flash device with two drives (= two host-side >> files), which is the incentive for this change. > > There's no fundamental reason why a single device model instance could > not be backed by two block backends, named by two drive properties. > > I'm not claiming this is the best solution, just offering it for > consideration. I'll pass :) I guess in theory we could push down the multi-drive thing to "pflash_cfi01.c". But: - It is used by a bunch of other boards. - Regarding i386, the second drive could automatically become (dependent on the first drive's size) part of the range that is mirrored in isa-bios space. Probably not intended. - The previous point strengthens the "pflash is used by other boards too" concern: in case of i386, I'm at least halfway aware of the board-specific consequences of sneaking in another drive, but I have no clue about the other boards. - If we decide at some point to map / paste backing drives in a loop, then the (at that time) existent device properties of pflash, let's call them "drive0" and "drive1", will look clumsy. We'll need a way to parse an unknown number of backend (drive) IDs. A mess. Thanks! Laszlo