Re: [libvirt] Configuring pflash devices for OVMF firmware
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.