From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53200) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlgMs-0002wg-L6 for qemu-devel@nongnu.org; Wed, 27 Nov 2013 09:45:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlgMm-0006lq-3t for qemu-devel@nongnu.org; Wed, 27 Nov 2013 09:45:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32947) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlgMl-0006lk-RC for qemu-devel@nongnu.org; Wed, 27 Nov 2013 09:45:24 -0500 From: Markus Armbruster 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> Date: Wed, 27 Nov 2013 15:45:11 +0100 In-Reply-To: <5295FB20.1000007@redhat.com> (Laszlo Ersek's message of "Wed, 27 Nov 2013 15:01:04 +0100") Message-ID: <8761rd52fc.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain 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: Laszlo Ersek Cc: "edk2-devel@lists.sourceforge.net" , Jordan Justen , qemu-devel , Cole Robinson 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.