Paolo Bonzini <[email protected]> writes:
> 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.
What exactly do you have in mind? Something like
-machine q35,ovmf-code=OVMF-CODE-NODE,ovmf-data=OVMF-DATA-NODE
where OVMF-CODE-NODE and OVMF-DATA-NODE are block backend node names,
i.e.
-blockdev
file,node-name=OVMF-CODE-NODE,read-only=on,filename=/usr/share/edk2/ovmf/OVMF_CODE.fd
-blockdev file,node-name=OVMF-DATA-NODE,read-only=on,filename=...
perhaps?
[...]
--
libvir-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libvir-list
