qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"
Date: Mon, 9 Apr 2018 18:53:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]