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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
