Re: [PATCH v2 00/15] Firmware auto selection

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

 



On 3/7/19 1:04 PM, Daniel P. Berrangé wrote:
On Thu, Mar 07, 2019 at 10:29:10AM +0100, Michal Privoznik wrote:
v2 of:

   https://www.redhat.com/archives/libvir-list/2019-February/msg01503.html

As usual, you can find my patches at my github:

   https://github.com/zippy2/libvirt/commits/firmware_v2

diff to v1:
- Hopefully all Lazlo's comment are worked in (fixing the logic that
   chooses suitable firmware for secboot/SMM domains, commit message
   adjustements, sanity check for parsed FW descriptions, etc.)

- Added more debug messages around FW selection code, i.e. it'll be
   visible from the logs why given FS is not suitable (or that it is).

I've done a very quick review of the patches and the design and
overall implementation strategy looks good to me. A few misc
points

  - We ought to expose the list of firmware types supported
    in the domain capabilities, so mgmt apps can probe if
    uefi is available

Makes sense, I'll start working on this after these are merged.


  - What should we do about the 'nvram' config from /etc/libvirt/qemu.conf
    We can't get rid of it for a while, since the new firmware configs
    won't be widely supported by distros in forseeable future. In the
    places which currently use the 'nvram' config though, should we
    make sure we consult the firmware configs in prefereence to
    resolve the var store ?  Maybe your code is already doing this and
    I missed the logic from the diffs.

I think we can ignore 'nvram' from qemu.conf safely. The whole point of nvram variable is to define which varstore corresponds to which fw image. These pairs are consulted if and only if no template was specified in domain XML. With firmware autoselect I don't think we are going to fulfil the condition as my code takes whatever FW config said the path to NVRAM is and uses that as template for the domain. And even if FW config did not provide any NVRAM path (which can be viewed as bug IMO) then we would consult qemu.conf (or some hardwired defaults).


  - We support 'bios' and 'efi' right now, but QEMU also reoprts
    'openfirmware' and 'uboot' as supported types. In practice
    no config files probably exist for those yet, but if it is
    easy to make the code support them we should try todo it to
    get parity with the QEMU spec

Sure. It's just that I don't think there is a way to even configure thos via our domain XML, is there?


I don't think any of these are blockers though - all would work
as followup patches I expect.

Yes, agreed.

Michal

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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux