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.
