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.