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