Re: [libvirt] [RFC] Defining firmware (OVMF, et al) metadata format & file

On Wed, Mar 07, 2018 at 03:49:51PM +0100, Kashyap Chamarthy wrote: Let me expand on the problem & desired solution from libvirt's POV Currently, if you are happy with the default firmware for a particular machine type, life is easy. QEMU knows the right path to use automatically. This was fine until people started wanting to use UEFI firemware with x86_64 Q35 and/or aarch64 virt machine types, because Q35 defaults to SeaBIOS and aarch64 defaults to no firmware. So mgmt applications wanting to use UEFI have to provide a full path to the firmware to libvirt. firmware type eg for x86_64 we want to allow apps to just do either <os firmware="bios"/> or <os firmware="efi"/> and then have libvirt automatically provide the best firmware image path to QEMU. We'll still allow apps to provide an explicit path themselves if they really want to, because if nothing else that's useful for people who need to test out ad-hoc firmware builds. IOW, in general if you (sysadmin/mgmt app) want to enable EFI for a guest, you should never need to care about firmware paths. This will give libvirt QEMU driver parity with what's possible for vmware guests in this area. With this in mind, when we talk about providing metadata files for firmware below, we should bear in mind that we likely want this metadata to be general purpose, not something specific to OVMF. IOW all existing QEMU firmware images, for all architetures should be covered & whatever custom firmware users might have. Not neccessarily just OVMF - anything that uses the same pflash config mechanism. We need to have ability to list machine types too, since historically there have been cases where we screwed up and needed to provide differnt builds of the same firmware to different machine types. I think we just need a well defined list of properties / features here as it might need to track morethan just SMM. We need to define what order the metadata files are processed in, so that if there are multuple firemware images that satisfy a given guest config, we have a predictable / determinstic choice. This could be as simple as recommending each filename start with a 2 digit number. eg 50-ovmf.json That lets end user drop in a 20-ovmf.json if they want to provide a different ovmf by default. IOW, we'll look at various things like firmware=efi|bios, and whether secure boot is requested for the guest. I don't think we actually have an explicit attribute for requesting secureboot=on|off, so we'd probably want to add one. THis is then used to pick the default firmware. As a specific non-goal: If multiple metadata files are all satisfactory for a given guest config, libvirt is just going to pick the first acceptable match. If users/apps want to have finer grained control, they can still pass an explicit path themselves as done today to override the default choice. NB, mgmt tools should never need to read the metadata files - they'll just request libvirt to use firmware=efi|bios, etc IMHO QEMU should be defining the format, because the file will contain info about certain QEMU features associated with the firmware (eg smm). Also there are potentially other non-libvirt mgmt apps that spawn QEMU which would like this info (eg libguestfs), so having libvirt define the format is inappropriate. I'd suggest we just need something in docs/specs/firmware-metadata.rst for QEMU source tree. Potentially QEMU could even use the metadata files itself for finding the default firmeware images, instead of compiling this info into its binaries. I wouldn't suggest we need todo that right away, but bear it in mind as a potential use case. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|