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