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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
