On 04/10/18 12:20, Daniel P. Berrangé wrote:
> On Sat, Apr 07, 2018 at 02:01:17AM +0200, Laszlo Ersek wrote:
>> +{ 'struct' : 'SystemFirmware',
>> + 'data' : { 'executable' : 'FirmwareFile',
>> + 'type' : 'SystemFirmwareType',
>> + 'targets' : [ 'str' ],
>> + 'sysfw-map' : 'FirmwareMapping',
>> + '*nvram-slots' : [ 'NVRAMSlot' ],
>> + '*supports-uefi-secure-boot' : 'bool',
>> + '*supports-amd-sev' : 'bool',
>> + '*supports-acpi-s3' : 'bool',
>> + '*supports-acpi-s4' : 'bool' } }
>
> Elsewhere in the thread I mentioned that I think we should try to use a
> union approach to isolate which information is relevant to "flash" loader
> format and which is relevant to "memory" and "kernel". To try to illustrate
> what I mean by that I've knocked up an alternative structure. I also
> incorporated the points about features & target/machine types. I've left
> out the read/write/etc fields, but they could be put back in at the
> relevant position
I think this looks very nice; with the addition of
- "requires-smm" to "SystemFirmwareFeature":
> { 'enum' : 'SystemFirmwareFeature',
> 'data': ['acpi-s3', 'acpi-s5', 'secure-boot', 'amd-sev' ]}
- and another feature flag (perhaps in SystemFirmwareFeature, perhaps in
SystemFirmwareBinaryFlashVars) for the cmdline option "-global
driver=cfi.pflash01,property=secure,value=on",
this could be called a day as far as SeaBIOS and OVMF are concerned.
Thanks
Laszlo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
