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