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

2018-04-10 Thread Laszlo Ersek
On 04/10/18 12:09, Paolo Bonzini wrote:
> On 10/04/2018 11:23, Daniel P. Berrangé wrote:
>>> And, really, this seems to reinforce my point that the schema should
>>> live in the libvirtd tree, not in the QEMU tree. In that case, perhaps
>>> it would be a better fit to work with an XSD, and firmware packages
>>> should install XML files? Personally I'm a lot more attracted to
>>> XML/XSD; I think the tooling is better too. I just don't see how QEMU is
>>> involved.
>>
>> This is defining a set of metadata that is required to use various firmware
>> files in combination with QEMU, along with defining a mapping to QEMU command
>> line arguments and/or features. Essentially, while I wish everyone used
>> libvirt, libvirt is not the only thing that manages QEMU. This information is
>> relevant to anyone managing QEMU, so it doesn't belong in libvirt's realm,
>> it is clear QEMU is best placed to declare this information.
> 
> QEMU is best placed to _standardize_ how to provide this information
> (and where in the file system to place it), but really it's up to
> firmware packages to provide it.
> 
> We can of course define the schema in QAPI terms for ease of validation
> (machine-readable specs are nice to have), but really this should just
> be a file in docs/interop/.  No code is needed in QEMU.

OK -- while we're figuring out the schema, I guess I'll keep posting
RFCs that change source code / json, but finally we can move it to
docs/interop.

Thanks!
Laszlo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

2018-04-10 Thread Gerd Hoffmann
  Hi,

> It occurs to me that we are actually over-thinking things, by making it
> possible to list a choice of vars files per firmware. We could remove this
> special case by just having separate tpo level firmware entries and a main
> feature flag to say if it is enrolled or not - see below example

That would also make it easier to implement something like ...

qemu -firmware json=/path/to/firmware/spec.json

... because you simply have two files for the enrolled/non-enrolled
variants.

cheers,
  Gerd

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


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

2018-04-10 Thread Daniel P . Berrangé
On Tue, Apr 10, 2018 at 11:20:33AM +0100, Daniel P. Berrangé wrote:
> On Sat, Apr 07, 2018 at 02:01:17AM +0200, Laszlo Ersek wrote:
> > Add a schema that describes the properties of virtual machine firmware.
> > 
> > Each firmware executable installed on a host system should come with a
> > JSON file that conforms to this schema, and informs the management
> > applications about the firmware's properties.
> > 
> > In addition, a configuration directory with symlinks to the JSON files
> > should exist, with the symlinks carefully named to reflect a priority
> > order. Management applications can then search this directory in priority
> > order for the first firmware executable that satisfies their search
> > criteria. The found JSON file provides the management layer with domain
> > configuration bits that are required to run the firmware binary.
> > 
> 
> > diff --git a/qapi/firmware.json b/qapi/firmware.json
> > new file mode 100644
> > index ..f267240f44dd
> > --- /dev/null
> > +++ b/qapi/firmware.json
> 
> [snip]
> 
> > +{ '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
> 
> 
> { 'enum' : 'SystemFirmwareType',
>   'data' : [ 'bios', 'slof', 'uboot', 'uefi' ] }
> 
> { 'enum' : 'SystemFirmwareDevice',
>   'data' : [ 'memory', 'kernel', 'flash' ] }
> 
> { 'enum' : 'SystemFirmwareArchitecture',
>   'data':  ['x86_64', 'i386', ..etc.. ] }
>   
> { 'enum' : 'SystemFirmwareFeature',
>   'data': ['acpi-s3', 'acpi-s5', 'secure-boot', 'amd-sev' ]}
> 
> 
> ## Struct(s) for device==memory
> 
> { 'struct': 'SystemFirmwareBinaryMemory',
>   'data': { 'pathname': 'str' } }
> 
> 
> ## Struct(s) for device==kernel
> 
> { 'struct': 'SystemFirmwareBinaryKernel',
>   'data': { 'pathname': 'str' } }
> 
> 
> ## Struct(s) for device==flash
> 
> { 'struct': 'SystemFirmwareBinaryFlashFile',
>   'data':  { 'filename': 'str',
>  'format': 'BlockdevDriver' } }
> 
> { 'struct': 'SystemFirmwareBinaryFlashCode',
>   'base': 'SystemFirmwareBinaryFlashFile' }
> 
> { 'struct': 'SystemFirmwareBinaryFlashVars',
>   'base': 'SystemFirmwareBinaryFlashFile',
>   'data': { 'secure-boot-key-enroll': 'bool' } }
> 
> { 'struct': 'SystemFirmwareBinaryFlash',
>   'data': { 'code': 'SystemFirmwareBinaryFlashCode',
> 'vars': ['SystemFirmwareBinaryFlashVars' ] } }
> 
> 
> ## Discriminated struct for different loading approaches
> 
> { 'union': 'SystemFirmwareBinary',
>   'base': { 'device': 'SystemFirmwareDevice' },
>   'discriminator': 'device',
>   'data': { 'memory': 'SystemFirmwareBinaryMemory',
> 'kernel': 'SystemFirmwareBinaryKernel',
> 'flash': 'SystemFirmwareBinaryFlash' } }
> 
> 
> 
> { 'struct' : 'SystemFirmwareTarget',
>   'data': { 'architecture': 'SystemFirmwareArchitecture',
> 'machines': [ 'str' ] } }
> 
> 
> { 'struct' : 'SystemFirmware',
>   'data'   : {
>   'description'  : 'str',
>   'type' : 'SystemFirmwareType',
>   'binary'   : 'SystemFirmwareBinary',
>   'targets'  : [ 'SystemFirmwareTarget' ],
>   'features' : ['SystemFirmwareFeature'] } } 
> 
> 
> 
> # Examples:
> #
> # {
> #'description': 'SeaBIOS 256k',
> #'type': 'bios',
> #'binary': {
> #'type': 'memory',
> #'filename': '/path/to/seabios/rom-256k',
> #}
> #'targets':  {
> #'x86_64': [ "pc", "q35"],
> #'i386': [ "pc", "q35"],
> #}
> #'features': ['acpi-s3', 'acpi-s5'],
> # }
> # {
> #'description': 'SeaBIOS 128k',
> #'type': 'bios',
> #'binary': {
> #'type': 'memory',
> #'filename': '/path/to/seabios/rom-128k',
> #}
> #'targets':  {
> #'x86_64': [ "isapc"],
> #'i386': [ "isapc"],
> #}
> #'features': [],
> # }
> # {
> #'description': 'OVMF',
> #'type': 'uefi'
> #'binary': {
> #'type': 'flash',
> #'code': {
> #  'filename': '/usr/share/OVMF/OVMF_CODE.secboot.fd',
> #  'format': 'raw',
> #

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

2018-04-10 Thread Paolo Bonzini
On 10/04/2018 11:23, Daniel P. Berrangé wrote:
>> And, really, this seems to reinforce my point that the schema should
>> live in the libvirtd tree, not in the QEMU tree. In that case, perhaps
>> it would be a better fit to work with an XSD, and firmware packages
>> should install XML files? Personally I'm a lot more attracted to
>> XML/XSD; I think the tooling is better too. I just don't see how QEMU is
>> involved.
>
> This is defining a set of metadata that is required to use various firmware
> files in combination with QEMU, along with defining a mapping to QEMU command
> line arguments and/or features. Essentially, while I wish everyone used
> libvirt, libvirt is not the only thing that manages QEMU. This information is
> relevant to anyone managing QEMU, so it doesn't belong in libvirt's realm,
> it is clear QEMU is best placed to declare this information.

QEMU is best placed to _standardize_ how to provide this information
(and where in the file system to place it), but really it's up to
firmware packages to provide it.

We can of course define the schema in QAPI terms for ease of validation
(machine-readable specs are nice to have), but really this should just
be a file in docs/interop/.  No code is needed in QEMU.

Paolo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list