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