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