Since we are not passing the @fakerootdir variable to any inline function
anymore, we can make the variable static.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Now that function is no longer used, it can be dropped.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Now that function is no longer used, it can be dropped.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
In my previous commit of v5.9.0-83-g4ae7181376 I've fixed
check-aclrules but whilst doing so, I forgot to wrap long
lines that I've added.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Previously we generated all source files into $srcdir which is no
longer true. This means that we can't just blindly prepend each
source file with $srcdir.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Previously we generated all source files into $srcdir which is no
longer true. This means that we can't just blindly prepend each
source file with $srcdir.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There are two ways for specifying loader:nvram pairs:
1) --with-loader-nvram configure option
2) nvram variable in qemu.conf
Since we have FW descriptors, using this old style is
discouraged, but not as strong as one would expect. Produce more
warnings:
1) produce a warning if somebody tries the configure option
2) produce a warning if somebody sets nvram variable and at
least on FW descriptor was found
The reason for producing warning in case 1) is that package
maintainers, who set the configure option in the first place
should start moving towards FW descriptors and abandon the
configure option. After all, the warning is printed into config
output only in this case.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1763477
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In commit 0985a9597b we stopped
distributing generated source file. This is done by prepending
binary_SOURCES variable with "nodist_". However, there is a typo
- the prefix is "nodst_" instead of "nodist_".
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The qemuDomainGetStatsIOThread() accesses the monitor by calling
qemuDomainGetIOThreadsMon(). And it's also marked as "need
monitor" in qemuDomainGetStatsWorkers[]. However, it's not
checking if acquiring job was successful.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The qemuDomainObjEnterMonitor() should not be called without a
job set. Catch this error and produce a warning message if such
call occurred.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
In few places we have the following code pattern:
int ret;
... /* @ret is not accessed here */
ret = f(...);
return ret;
This pattern can be written less verbose:
...
return f(...);
This patch was generated with following coccinelle spatch:
@@
type T;
constant C;
expression f;
identifier ret;
@@
-T ret = C;
... when != ret
-ret = f;
-return ret;
+return f;
Afterwards I needed to fix a few places, e.g. comment in
virDomainNetIPParseXML() was removed too because coccinelle
thinks it refers to @ret while in fact it doesn't. Also in few
places it replaced @ret declaration with a few spaces instead of
removing the line. But nothing terribly wrong.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
In v5.8.0-332-g3097282d86 the libvirt-admin.so was moved into
src/admin/ directory. However, corresponding .gitignore change
was left out.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
These two functions have pattern that's preventing us from
simpler virAsprintf() -> g_strdup_printf() transition. Modify
their logic a bit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In a few places our code relies on the fact that virAsprintf()
not only prints to allocated string but also that it returns the
length of that string. Fortunately, only few such places were
identified:
https://www.redhat.com/archives/libvir-list/2019-September/msg01382.html
In case of virNWFilterSnoopLeaseFileWrite() and virFilePrintf()
we can use strlen() right after virAsprintf() to calculate the
length. In case of virDoubleToStr() it's only caller checks for
error case only, so we can limit the set of returned values to
just [-1, 0].
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In domain_conf.c we have virDomainSCSIDriveAddressIsUsed()
function which returns true or false if given drive address is
already in use for given domain config or not. However, it also
takes a shortcut and returns true (meaning address in use) if the
unit number equals 7. This is because for some controllers this
is reserved address. The limitation comes mostly from vmware and
applies to lsilogic, buslogic, spapr-vscsi and vmpvscsi models.
On the other hand, we were not checking for the maximum unit
number (aka LUN number) which is also relevant and differs from
model to model.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
So far, the virDomainDeviceFindSCSIController() takes
virDomainDeviceInfo structure which is an overkill. It assumes
that the passed structure is type of
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DRIVE which is not obvious.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This simplifies some functions, but mostly
libxlDomainManagedSavePath() which is going to be modified in
future commits.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There's unused 'error' label left after transition from
VIR_STRDUP() to g_strdup (v5.8.0-255-g652cdbe364).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The @freeTmpPath boolean is used to determine if @tmpPath holds
an allocated memory or is a pointer to a constant string and
therefore if it needs to be freed or not when returning from the
function. Well, we can unify the way we set @tmpPath so that it
always holds an allocated memory and thus always must be freed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
There are three cases where vir*DeviceGetPath() returns a const
string. In these cases, the string is initialized in
corresponding vir*DeviceNew() calls which fail if string couldn't
be allocated. There's no point in checking the second time if the
string is NULL.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Since its introduction in v1.0.5-rc1-19-g6e13860cb4 the
qemuTeardownHostdevCgroup() does nothing unless the passed
hostdev is a PCI device with VFIO backend. This seems
unnecessary.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
There are two types of host devices that require /dev/vfio/vfio
access:
1) PCI devices with VFIO backend
2) Mediated devices
Introduce a simple helper that returns true if passed @hostdev
falls in either of the categories.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
In some places we need to check if a hostdev has VFIO backend.
Because of how complicated virDomainHostdevDef structure is, the
check consists of three lines. Move them to a function and
replace all checks with the function call.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
These functions do not change any of the passed hostdevs. They
just read them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
These functions don't really abort() on OOM. The fix was merged
upstream, but not in the minimal version we require. Provide our
own implementation which can be removed once we bump the minimal
version.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
With glib inclusion, some of its functions have
__attribute__((__malloc__)) which make compiler realize we want
to use the same attribute for some trivial functions of ours. For
instance qemuDomainManagedSavePath(). I don't see any real
benefit into using the attribute, so disable that suggestion.
In fact, wrong use of the attribute may lead to mysterious bugs:
https://gitlab.gnome.org/GNOME/glib/issues/1465
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
ACKed-by: Peter Krempa <pkrempa@redhat.com>
In order to have multiple security drivers hidden under one
virSecurity* call, we have virSecurityStack driver which holds a
list of registered security drivers and for every virSecurity*
call it iterates over the list and calls corresponding callback
in real security drivers. For instance, for
virSecurityManagerSetAllLabel() it calls
domainSetSecurityAllLabel callback sequentially in NOP, DAC and
(possibly) SELinux or AppArmor drivers. This works just fine if
the callback from every driver returns success. Problem arises
when one of the drivers fails. For instance, aforementioned
SetAllLabel() succeeds for DAC but fails in SELinux in which
case all files that DAC relabelled are now owned by qemu:qemu (or
whomever runs qemu) and thus permissions are leaked. This is even
more visible with XATTRs which remain set for DAC.
The solution is to perform a rollback on failure, i.e. call
opposite action on drivers that succeeded.
I'm providing rollback only for set calls and intentionally
omitting restore calls for two reasons:
1) restore calls are less likely to fail (they merely remove
XATTRs and chown()/setfilecon() file - all of these operations
succeeded in set call),
2) we are not really interested in restore failures - in a very
few places we check for retval of a restore function we do so
only to print a warning.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1740024
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
In near future we will need to walk through the list of internal
drivers in reversed order. The simplest solution is to turn
singly linked list into a doubly linked list.
We will not need to start from the end really, so there's no tail
pointer kept.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
This function returns the name of the secdriver. Since the name
is invariant we don't really need to lock the manager - it won't
change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
This function is in fact returning the name of the virtualization
driver that registered the security manager/driver.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
In upcoming commits, virSecurityManagerSetAllLabel() will perform
rollback in case of failure by calling
virSecurityManagerRestoreAllLabel(). But in order to do that, the
former needs to have @migrated argument so that it can be passed
to the latter.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1755803
The /dev/tpmN file can be opened only once, as implemented in
drivers/char/tpm/tpm-dev.c:tpm_open() from the kernel's tree. Any
other attempt to open the file fails. And since we're opening the
file ourselves and passing the FD to qemu we will not succeed
opening the file again when locking it for seclabel remembering.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
While in most cases we want to remember/recall label for a
chardev, there are some special ones (like /dev/tpm0) where we
don't want to remember the seclabel nor recall it. See next
commit for rationale behind.
While the easiest way to implement this would be to just add new
argument to virSecurityDACSetChardevLabel() this one is also a
callback for virSecurityManagerSetChardevLabel() and thus has
more or less stable set of arguments. Therefore, the current
virSecurityDACSetChardevLabel() is renamed to
virSecurityDACSetChardevLabelHelper() and the original function
is set to call the new one.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
So far all items on the chown/setfilecon list have the same
.remember value. But this will change shortly. Therefore, don't
try to lock paths which we won't manipulate XATTRs for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
When constructing QMP capabilities we allocate a dummy domain
object to pass to qemuMonitorOpen(). However, after 75dd595861
the function also expects domain definition to be allocated for
the domain object. The referenced commit already fixed
qemumonitortestutils.c but forgot to fix the other caller:
qemuProcessQMPConnectMonitor().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This reverts commit a5a777a8ba.
After previous commit the domain won't disappear while connecting
to monitor. There's no need to ref monitor config then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
When connecting to qemu's monitor the @vm object is unlocked.
This is justified - connecting may take a long time and we don't
want to wait with the domain object locked. However, just before
the domain object is locked again, the monitor's FD is registered
in the event loop. Therefore, there is a small window where the
event loop has a chance to call a handler for an event that
occurred on the monitor FD but vm is not initalized properly just
yet (i.e. priv->mon is not set). For instance, if there's an
incoming migration, qemu creates its socket but then fails to
initialize (for various reasons, I'm reproducing this by using
hugepages but leaving the HP pool empty) then the following may
happen:
1) qemuConnectMonitor() unlocks @vm
2) qemuMonitorOpen() connects to the monitor socket and by
calling qemuMonitorOpenInternal() which subsequently calls
qemuMonitorRegister() the event handler is installed
3) qemu fails to initialize and exit()-s, which closes the
monitor
4) The even loop sees EOF on the monitor and the control gets to
qemuProcessEventHandler() which locks @vm and calls
processMonitorEOFEvent() which then calls
qemuMonitorLastError(priv->mon). But priv->mon is not set just
yet.
5) qemuMonitorLastError() dereferences NULL pointer
The solution is to unlock the domain object for a shorter time
and most importantly, register event handler with domain object
locked so that any possible event processing is done only after
@vm's private data was properly initialized.
This issue is also mentioned in v4.2.0-99-ga5a777a8ba.
Since we are unlocking @vm and locking it back, another thread
might have destroyed the domain meanwhile. Therefore we have to
check if domain is still active, and we have to do it at the
same place where domain lock is acquired back, i.e. in
qemuMonitorOpen(). This creates a small problem for our test
suite which calls qemuMonitorOpen() directly and passes @vm which
has no definition. This makes virDomainObjIsActive() call crash.
Fortunately, allocating empty domain definition is sufficient.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1755303
With the recent work in daemon split and socket activation
daemons can come and go. They can and will be started many times
during a session which results in objects being autostarted
multiple times. This is not optimal. Use
virDriverShouldAutostart() to determine if autostart should be
done or not.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Some of objects we manage can be autostarted on libvirtd startup
(e.g. domains, network, storage pools). The idea was that when
the host is started up these objects are started too without need
of user intervention. However, with the latest daemon split and
switch to socket activated, short lived daemons (we put --timeout
120 onto each daemon's command line) this doesn't do what we want
it to. The problem is not new though, we already had the session
daemon come and go and we circumvented this problem by
documenting it (see v4.10.0-92-g61b4e8aaf1). But now that we meet
the same problem at all fronts it's time to deal with it.
The solution implemented in this commit is to have a file (one
per each driver) that:
1) if doesn't exist, is created and autostart is allowed for
given driver,
2) if it does exist, then autostart is suppressed for given
driver.
All the files live in a location that doesn't survive host
reboots (/var/run/ for instance) and thus the file is
automatically not there on fresh host boot.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The comment says that the function kills domains and networks.
This is obviously not the case.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In the domain capabilities XML there are FW image paths printed.
There are two sources for the image paths (in order of
preference):
1) firmware descriptor files - as returned by
qemuFirmwareGetSupported()
2) a compile time list of FW:NRAM pairs which can be overridden
in qemu.conf
If either of those contains a duplicate FW image path (which is
a valid use case) it is printed twice in the capabilities XML.
While it's technically not a bug, it doesn't look good.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Tested-by: Kashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
If a symbol file for either of NSS modules is changed then
subsequent 'make' doesn't regenerate the library, because there
is no implicit dependency between the library and symbols file.
Put an explicit dependency into the Makefile then. Unfortunately,
setting _DEPENDENCIES makes us lose automake's generated
dependencies (see src/Makefile.am:592 for details). But
fortunately, the only dependency we had was _LIBADD variable.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Similarly to gethostbyname3(), the @addr must be freed on return
from the function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The findLease() function allocates @addr array iff no error
occurred and at least one satisfactory record was found.
Therefore, there is no need to call free() if findLease() failed,
or did not find any records as addr == NULL.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
When parsing leases file, appendAddr() is called to append parsed
tuple (address, expiry time, family) into an array. Whilst doing
so, the array is searched for possible duplicate. This is done by
comparing each item of the array by passed @family: if @family is
AF_INET then the item is viewed as IPv4 address. Similarly, if
@family is AF_INET6 then the item is viewed as IPv6 address. This
is not exactly right - the array can contain addresses of both
families and thus the address family of each item of the array
must be considered.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
As it turns out, on my 32bit ARM machine size_t is not the same
size as ULL. However, @length argument for both functions is type
of size_t but it's treated as ULL - for instance when passed to
qemuMonitorJSONMakeCommand(). The problem is that because of
"U:size" the virJSONValueObjectAddVArgs() expects an ULL argument
but on the stack there are size_t and char * arguments (which
coincidentally add up to size of ULL). So the created command has
only two arguments "val" and incorrect "size" and no "path" which
is required.
I've tried to find other occurrences of this pattern but at the
rest of places where size_t is used it tracks size of an array so
that's safe.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
ACKed-by: Peter Krempa <pkrempa@redhat.com>
The private data for video definition is created in
virDomainVideoDefNew() and we attempt to free it in
virDomainVideoDefFree(). This seems to work, except
the free function calls clear function which zeroes
out the whole structure and thus virObjectUnref()
which is called on private data does nothing.
2,568 bytes in 107 blocks are definitely lost in loss record 207 of 213
at 0x4A35476: calloc (vg_replace_malloc.c:752)
by 0x50A6048: virAllocVar (viralloc.c:346)
by 0x513CC5A: virObjectNew (virobject.c:243)
by 0x4DC1DEE: qemuDomainVideoPrivateNew (qemu_domain.c:1337)
by 0x51A6BD6: virDomainVideoDefNew (domain_conf.c:2831)
by 0x51B9F06: virDomainVideoDefParseXML (domain_conf.c:15541)
by 0x51CB761: virDomainDefParseXML (domain_conf.c:21158)
by 0x51C5973: virDomainDefParseNode (domain_conf.c:21708)
by 0x51C583A: virDomainDefParse (domain_conf.c:21663)
by 0x51C58AE: virDomainDefParseFile (domain_conf.c:21688)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Turns out, block mirror is not the only job a disk can have. It
can also do commits of one layer into the other. Or possibly some
other tricks too. Problem is that while we set seclabels on given
layers of backing chain when the job is starting (via
qemuDomainStorageSourceAccessAllow()) we don't restore them when
job finishes. This leaves XATTRs set and corresponding images
unusable.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
ACKed-by: Peter Krempa <pkrempa@redhat.com>
In bc1e924cf0 we've introduced video driver name and whilst
doing so we've utilized VIR_ENUM_IMPL() macro. Then, in domain
XML parsing code the generated
virDomainVideoBackendTypeFromString() is called and its return
value is assigned directly to an unsigned int variable which is
wrong. Also, the video driver enum has 'default' value which is
not formatted into domain XML but is accepted during parsing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This reverts commit 0cebb6422a.
This capability is not used anywhere and also it is not contained
in any release so it's safe to just remove it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The fact that qemu is capable -netdev socket is not enough to
start a migratable domain. It also needs dbus-vmstate capability.
Since there are already some qemu releases which have
net-socket-dgram capability and don't have dbus-vmstate we need
to check for dbus-vmstate.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemu side is not merged in yet, so there is a chance that the
interface will change. Don't detect the capability just yet then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The LIBVIRT_RESULT function takes two or three arguments. The
first one is the name of the result (aka CHECK_NAME). It is
printed before the colon character. The rest of the arguments is
printed after the character. To produce colourized output a
couple of changes needs to be made.
Firstly, we need to print the CHECK_NAME using "echo -n" so that
the new line is not appended at the end of the message. To
achieve this, AS_MESSAGE_N function is introduced. It's a
verbatim copy of AS_MESSAGE (which is just another alias to
AC_MSG_NOTICE) except it doesn't put '\n' at the EOL.
The alias is defined at /usr/share/autoconf-*/autoconf/general.m4
and the AS_MESSAGE is then defined at
/usr/share/autoconf-2.69/m4sugar/m4sh.m4.
Secondly, the rest of the arguments are printed colourized and to
achieve that and also keep printing them into the log file the
_AS_ECHO and COLORIZE_RESULT functions need to be called.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There is one hack hidden here, but since this is in a test, it's
okay. In order to get a list of expected firmwares in
virFirmwarePtr form I'm using virFirmwareParseList(). But
usually, in real life scenario, this function is used only to
parse a list of UEFI images which have NVRAM split out. In other
words, this function expects ${FW}:${NVRAM} pairs. But in this
test, we also want to allow just a single path: ${FW} because
some reported firmwares are just a BIOS image really. To avoid
writing some parser function, let's just pass "NULL" as ${NVRAM}
and fix the result later.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
The qemuFirmwareGetSupported() function is called from qemu
driver to generate domain capabilities XML based on FW descriptor
files. However, the function currently reports only some features
from domcapabilities XML and not actual FW image paths. The paths
reported in the domcapabilities XML are still from pre-FW
descriptor era and therefore the XML might be a bit confusing.
For instance, it may say that secure boot is supported but
secboot enabled FW is not in the listed FW image paths.
To resolve this problem, change qemuFirmwareGetSupported() so
that it also returns a list of FW images (we have the list
anyway). Luckily, we already have a structure to represent a FW
image - virFirmware.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Michal Privoznik