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

[Markus Armbruster]

Laszlo Ersek <address@hidden> writes:

> On 11/27/13 15:45, Markus Armbruster wrote:
>> Laszlo Ersek <address@hidden> writes:
>> 
>>> On 11/27/13 14:52, Markus Armbruster wrote:
>>>> Jordan Justen <address@hidden> writes:
>>>>
>>>>> On Tue, Nov 26, 2013 at 5:32 AM, Laszlo Ersek <address@hidden> 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.

I suspect real hardware mirrors the last 128KiB of its only flash chip
regardless of where the write-protected part begins.

> - 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.

Perhaps the proper way to back partially writable flash contents isn't
splitting it into two devices, but backing a single device with a COW.
The backing file has initial contents (say BIOS image), the delta may
have additional contents (say non-volatile configuration), and picks up
whatever the device model permits to be written to the flash.