Re: [Qemu-devel] [qemu PATCH] hw/i386/pc_sysfw: support more than one flash drive

[Laszlo Ersek <lersek@redhat.com>]

On 11/27/13 15:45, Markus Armbruster wrote:
> 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.

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