From: Markus Armbruster <armbru@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: "edk2-devel@lists.sourceforge.net"
<edk2-devel@lists.sourceforge.net>,
Jordan Justen <jljusten@gmail.com>,
qemu-devel <qemu-devel@nongnu.org>,
Cole Robinson <crobinso@redhat.com>
Subject: Re: [Qemu-devel] [qemu PATCH] hw/i386/pc_sysfw: support more than one flash drive
Date: Wed, 27 Nov 2013 15:45:11 +0100 [thread overview]
Message-ID: <8761rd52fc.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <5295FB20.1000007@redhat.com> (Laszlo Ersek's message of "Wed, 27 Nov 2013 15:01:04 +0100")
Laszlo Ersek <lersek@redhat.com> writes:
> On 11/27/13 14:52, Markus Armbruster wrote:
>> Jordan Justen <jljusten@gmail.com> writes:
>>
>>> On Tue, Nov 26, 2013 at 5:32 AM, Laszlo Ersek <lersek@redhat.com> 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.
next prev parent reply other threads:[~2013-11-27 14:45 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-21 22:21 [Qemu-devel] [qemu PATCH] hw/i386/pc_sysfw: support more than one flash drive Laszlo Ersek
2013-11-21 22:21 ` [Qemu-devel] [edk2 PATCH] OvmfPkg: split the variable store to a separate file Laszlo Ersek
2013-11-22 9:27 ` [Qemu-devel] [edk2] " Paolo Bonzini
2013-11-22 11:46 ` Laszlo Ersek
2013-11-22 11:56 ` Paolo Bonzini
2013-11-22 12:12 ` Laszlo Ersek
2013-11-22 17:37 ` [Qemu-devel] " Jordan Justen
2013-11-22 18:43 ` Laszlo Ersek
2013-11-22 20:51 ` Jordan Justen
2013-11-22 20:54 ` Eric Blake
2013-11-22 21:18 ` Jordan Justen
2013-11-22 21:40 ` Laszlo Ersek
2013-11-22 21:45 ` Laszlo Ersek
2013-11-21 22:26 ` [Qemu-devel] [qemu PATCH] hw/i386/pc_sysfw: support more than one flash drive Eric Blake
2013-11-21 22:33 ` Laszlo Ersek
2013-11-22 12:21 ` Markus Armbruster
2013-11-22 18:30 ` Laszlo Ersek
2013-11-25 15:22 ` Markus Armbruster
2013-11-25 19:45 ` Laszlo Ersek
2013-11-26 12:36 ` Markus Armbruster
2013-11-26 13:32 ` Laszlo Ersek
2013-11-26 17:54 ` Jordan Justen
2013-11-27 13:52 ` Markus Armbruster
2013-11-27 14:01 ` Laszlo Ersek
2013-11-27 14:45 ` Markus Armbruster [this message]
2013-11-27 15:18 ` Laszlo Ersek
2013-11-27 17:22 ` Markus Armbruster
2013-11-27 17:34 ` Laszlo Ersek
2013-11-27 20:35 ` Markus Armbruster
2013-11-26 13:41 ` [Qemu-devel] [edk2] " Paolo Bonzini
2013-11-26 13:53 ` Laszlo Ersek
2013-11-26 14:06 ` Paolo Bonzini
2013-11-26 12:53 ` [Qemu-devel] " Markus Armbruster
2013-11-26 13:27 ` Laszlo Ersek
2013-11-27 13:49 ` Markus Armbruster
2013-11-27 14:01 ` Laszlo Ersek
2013-11-25 15:32 ` Markus Armbruster
2013-11-25 20:17 ` Laszlo Ersek
2013-11-26 13:11 ` Markus Armbruster
2013-11-26 13:39 ` Laszlo Ersek
2013-11-26 15:35 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8761rd52fc.fsf@blackfin.pond.sub.org \
--to=armbru@redhat.com \
--cc=crobinso@redhat.com \
--cc=edk2-devel@lists.sourceforge.net \
--cc=jljusten@gmail.com \
--cc=lersek@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.