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