On 1/31/22 14:18, Daniel P. Berrangé wrote:
On Mon, May 10, 2021 at 03:16:11PM +0200, Pavel Hrdina wrote:
When QEMU introduces new firmware features libvirt will fail until we list that feature in our code as well which doesn't sound right.
We should simply ignore the new feature until we add a proper support for it.
Reported-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Pavel Hrdina <phrdina@redhat.com> --- src/qemu/qemu_firmware.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
Re-visiting this patch....
During guest startup, libvirt parses all firmware descriptors and treats any errors during parsing as fatal.
The problem we were fixing here was that on the QEMU / EDK2 side a new firmware feature called 'amd-sev-es' was added which libvirt didn't know about, so all libvirt guests using <os firmware='efi'/> broke when a distro shipped a descriptor.
We semi-future proofed ourselves by ignoring unknown features hereafter.
I'm now coming to introduce a new feature in the firmware descriptors to allow for OVMF builds which have a read-only CODE and *NOT* VARs file at all.
Currently the firmware descriptor treats nvram path as mandatory and libvirt validates that.
IOW, as soon as I make the nvram path optional and some distro ships a firmware descriptor taking advantage of that, libvirt again breaks for all guests using <os firmware='efi'/>. I've thought about various different ways to handle this but can't figure out any way to support an VARs-free firmware descriptor in a way that's backwards compatible with libvirt's current parsing code.
This is my current qemu patch:
https://listman.redhat.com/archives/libvir-list/2022-January/msg01316.html
We weren't future proofed enough.
It is nice reporting errors when parsing firmware descriptors because it highlights real world mistakes.
It is bad reporting errors when parsing firmware descriptors because it introduces potential for bogus failure scenarios any time the spec is extended.
If we quit reporting errors and simply log a warning and ignore the firmware descriptor we couldn't parse entirely, then we are more robust if a completely new firmware descriptor is introduced - we can still parse existing firmware descriptor files and probably do something sensible.
On the flipside, if an existing firmware descriptor is modified and we ignore it due to some unexpected data being present, we cause a regression.
I feel like we're in a bit of a no-win situation here wrt error reporting and future proofing.
My gut feeling is that we have little choice but to rely on the OS distro not to introduce firmware descriptors with fields that libvirt is too old to support, except in limited scenarios like the features enum case below where we can reasonably ignore a very specific error.
Anyone have other ideas ?
I think it's sane requirement for distros to ship FW descriptors that libvirt understands. Or backport patches for libvirt. One way or another, if a mgmt app would want to use SEV it would need bleeding edge libvirt anyway. And we can use those number prefixes to make new firmware files de-prioritized so that users who don't care are not affected. Michal