On 04/09/18 10:26, Gerd Hoffmann wrote:
+# { +# "executable": { +# "pathname": "/usr/share/OVMF/OVMF_CODE.secboot.fd", +# "description": "OVMF with Secure Boot and SMM-protected varstore", +# "tags": [ +# "FD_SIZE_4MB", +# "IA32X64", +# "SECURE_BOOT_ENABLE", +# "SMM_REQUIRE" +# ] +# }, +# "type": "uefi", +# "targets": [ +# "x86_64" +# ], +# "sysfw-map": { +# "device": "flash", +# "write": "denied" +# }, +# "nvram-slots": [ +# { +# "slot-id": 1, +# "nvram-map" : { +# "device": "flash", +# "write": "restricted-to-secure-context" +# },
What is "slot-id"? The pflash index?
Yes, it might be defined like that, for the i440fx and q35 machine types. This correspondence would be implemented in libvirtd, I suppose. However, I don't think such a correspondence is mandatory. At first approach, slot-id is just the key that tells the nvramslots apart.
shouldn't we also specify the index for the executable somewhere?
Maybe :)
Maybe the field should be moved into FirmwareMapping?
I couldn't come up with a good use case where you wouldn't map the *system* firmware in a predefined pflash unit (or other device unit). So I thought that needed no slot-id. Thanks Laszlo