[libvirt] [Qemu-devel] Configuring pflash devices for OVMF firmware

[Markus Armbruster]

Peter Maydell <peter.maydell at linaro.org> writes:

> On Mon, 28 Jan 2019 at 12:40, Gerd Hoffmann <kraxel at redhat.com> wrote:
>> The tricky part is the access control here.  On physical hardware you
>> typically have one flash rom, say 16M below 4G (on x86).
>>
>> Our pflash device doesn't allow to define multiple regions, so we use
>> multiple pflash devices instead, each with different access permissions
>> (code vs. vars).  Because of that they are more dynamic than they are on
>> phyiscal hardware, x86 sizes them according to the size of the firmware
>> images (arm is easier here, we have fixed size and location no matter
>> how big the firmware images are).
>>
>> So I think the options we have are:
>>   (a) leave pflash as-is, which pretty much implies physaddr and size
>>       must be user-configurable.
>>   (b) add support for multiple regions to pflash, so one can attach
>>       multiple blockdev at different offsets to a single pflash device.
>
> The latter makes more sense to me -- we should model what the
> hardware actually has, because the guest can tell the difference.

No argument.

> (Migration compat is left as an exercise for the reader :-))

It's not just migration compatibility, it's also guest ABI: "the guest
can tell the difference".  So, old machine types continue to get two
flash devices, and new machine types get one.  In other words, we're
stuck maintaining (a) even if we decide to switch to (b).

By itself, not an argument against doing the right thing for new machine
types.  It's an argument for trying harder doing the right thing from
the start next time.

I'm not sure whether doing the right thing now is worthwhile from a
practical point of view.

I figure the need for a region-capable flash device model may well come
up again in contexts other than PC firmware.  Perhaps we should discount
the cost of creating it when weighing the tradeoff for PC.