On 30/01/19 15:13, Markus Armbruster wrote:
-global driver=cfi.pflash01,property=secure,value=on
Affects *all* such devices, but fortunately we have at most two, and the one we don't want to affect happens to ignore the property value.
Is this true? I think both need secure=on, at least on x86.
For libvirt, plumbing the base address from the firmware's descriptor to QEMU would be the lesser mess (for the firmware, providing the base address there would be no mess at all).
For human users, it's perhaps the greater mess. They can continue to use -drive if=pflash.
Perhaps we *should* redo board configuration from the ground up. Perhaps a board should be a composite object that exposes properties of its own and its part, just like other composite devices, and so that "create, set properties, realize" works. That would extend our common device configuration mechanism naturally to onboard devices.
Of course, "we should" doesn't imply "I could".
Maybe we should just add pflash block properties to the machine? And then it can create the devices if the properties are set to a non-empty value. This doesn't remove the need to use -global to configure the "secure" property, but it's not particularly an issue. Paolo