Re: [Qemu-devel] Configuring pflash devices for OVMF firmware

[Markus Armbruster <armbru@redhat.com>]

The thread got long, let me try to summarize, and elaborate a few
points.

* The problem at hand is configuring firmware residing in flash memory
  (OVMF requires this) without legacy -drive.

* The wider problem is configuring onboard devices.  Our general device
  configuration interface doesn't cover them.  Instead, we have a zoo of
  ad hoc interfaces that are much more limited.  Some of them we'd
  rather deprecate (-drive, -net), but can't until we have a suitable
  replacements.

  I think a board should be a composite object that exposes properties
  of its own and its parts, just like other composite devices, so that
  "create, set properties, realize" just works.  That would extend our
  common device configuration mechanism naturally to onboard devices.

  A PC board's flash memory device would be just another part.  It could
  be something like /machine/q35/cfi.pflash01/ in the QOM tree.  To
  configure it, you'd set its properties, such as
  /machine/q35/cfi.pflash01/drive.

  Note that this requires a way to set an existing device's properties.
  Perhaps qom-set already works.

* While I do believe we should tackle the wider problem, I'd rather not
  sit on the narrow problem until we crack it.  So, what can we do about
  it?

  - Paolo proposed to add block backend properties to the PC machine,
    settable like -machine pflash0=BLOCK-BACKEND.

    Possible drawback: if we add /machine/q35/pflash0 to the QOM tree
    now, and later replace it by /machine/q35/cfi.pflash01/drive, we'll
    have to deal with yet another machine type variation.  We'll live.

  - I proposed to sidestep our onboard device configuration problem by
    adding the cfi.pflash01 devices with our existing general device
    configuration interface: -device.  Possible since the onboard
    cfi.pflash01 devices are optional.  Requires a small extension to
    the firmware descriptors, and a bit of extra work in libvirt to
    process that extension.  I think it's workable, but Paolo's idea is
    simpler.

  I can give Paolo's idea a try.  Objections?

* A flash device supporting multiple regions is desirable, because it's
  what physical hardware has.  We currently use multiple flash devices
  instead.  We'll be stuck with them for existing machine types due to
  guest ABI and migration compatibility.

* cfi.pflash01 currently requires users to opt out of "bad, do not use".
  It should require opt in, to guard against accidental new uses of
  "bad".


PS: Big thanks to László, whose patient guidance helped me map this part
of the jungle.