Add a config where both DIMM and non-DIMM <memory> devices are used so
that it validates that only DIMMs require memory slots.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We allow (some) domain devices to have a different <seclabel/>
than the top level domain one (this is mostly to allow access to
a resource for multiple domains). Now, we do couple of sanity
checks for such <seclabel/>, e.g. when the <label/> is specified,
but '@relabel' is set to no. But what we are missing is the
opposite: when '@relabel' is set, but no <label/> was provided.
Our schema already denies such combination. Make our parser
behave the same.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160356
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We already do check that if there's <memory mode='restrictive'/>
then all <memnode/> have to be of 'restrictive' mode too. But
what we are missing the reverse: if there is <memnode/> with
'restrictive' mode, then the <memory/> has to be of the same mode
too.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2208946
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The parser makes the values mandatory and also the qemu code implements
actions for those values. The formatter skips them though. Since
format+parse is used to copy the XML at startup a definition with those
values can't be started.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2203709
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Convert all of the 'audio-default-*' cases to use capabilities from
qemu-4.2 instead of the fake caps.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Drop the unnecessary disk definition and use x86_64 emulator.
For 'qemuxml2argvtest' replace the fake-caps invocation by a 4.2.0
version-locked invocation and add a '_CAPS_LATEST' invocation.
For 'qemuxml2xmltest' convert to use '_CAPS_LATEST' only.
There are no sound-device relevant changes in the output files.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test case is a subset of what the 'sound-device' case tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When preparing a SCSI <hostdev/> with passthrough of a host SCSI
adapter (i.e. no protocol), a virStorageSource structure is
initialized and stored inside virDomainHostdevDef. But the source
structure is filled in many places, with almost the same code.
Firstly, qemuProcessPrepareHostHostdev() and
qemuConnectDomainXMLToNativePrepareHostHostdev() are the same.
Secondly, qemuDomainPrepareHostdev() allocates the src structure,
only to let qemuProcessPrepareHostHostdev() fill src->path later.
Well, src->path can be filled at the same place where the src
structure is allocated (qemuDomainPrepareHostdev()) which renders
the other two functions needless.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The qemuxml2argvtest does a bit of 'fixups' to parsed
virDomainDef just before generating the cmd line. For instance,
it sets PCI backend for hostdevs (to VFIO). The reason for this
is that we want to make the test host independent and thus
letting the code chose backend at runtime might render different
results on different machines. But this is not necessary, as
virpcimock (that the test uses) already creates a fake, but
stable environment (where /dev/vfio/vfio and IOMMU groups exist),
thus qemuHostdevHostSupportsPassthroughVFIO() returns true,
regardless of the actual host support.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Treat:
<maxphysaddr mode="emulate"/>
as a request not to take the maximum address size from the host.
This is useful if QEMU changes the default.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
That's already the case in practice, but it's a better
experience for the user if we reject this configuration
outright instead of silently ignoring part of it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce a small kludge in the parser to avoid unnecessarily
blocking incoming migration from a range of recent libvirt
releases.
https://bugzilla.redhat.com/show_bug.cgi?id=2184966
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All supported qemu versions at this point support both 'qemu-xhci' and
'nec-xhci' controllers. To allow using real capabilities restructure the
tests so that we test both controllers explicitly as well as the
selection of the default model.
Also add a xml2xml test invocation of the unified test.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The fake-caps version was kept as an example that the code behaves the
same with real capabilities. Now it's not needed any more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
With all supported qemu versions we'll pick PCIe to use for the implicit
address busses (those lacking an explicit controller) and thus the
addresses must reflect that.
Update the test to add the new flags, and fix the addresses.
Additionally add a real-caps version of the test.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use real caps and clear out flags for PCIe so that we have a real-ish
example of an aarch64 machine using mmio.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test data is effectively identical to the
'aarch64-virtio-pci-default' case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a version for 'latest' caps as well as '4.2.0'. The test
demonstrates that with a real qemu PCIe will be used instead of MMIO.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert the two negative cases to use real capapbilities as well as the
positive case for situations when KVM is not used by stripping the
QEMU_CAPS_KVM flag.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert 'aarch64-gic-default' and 'aarch64-gic-none' cases to use real
capabilities both latest and locked to 4.2.0 to show what would happen
with a real qemu.
Note that the qemuTestSetHostArch() calls are needed as real caps
override the setting once used. Once we convert all tests to real data
this can be dropped.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert the rest of the outstanding tests to use real capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use real capabilities for the CPU test. The negative test case for QEMUs
without QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION is removed as the feature is
now supported by all supported qemu versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'hostdev-subsys-mdev-vfio-ccw', 'hostdev-vfio-zpci', and
'hostdev-vfio-zpci-autogenerate-fids' test cases have negative versions
which are invoked without capabilities. This does not make sense going
forward as the tests are going to be switched to real capabilities.
Remove them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert the last outstanding test cases for ppc64 to use real
capabilities.
In couple cases this actually fixes the test case to test what it was
intending to do.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All of the tested features are always present in the 'pseries' machine
with oldest-supported qemu-4.2, thus the tests don't make sense any
more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add an example case showing that every feature in the 'pseries-features'
test works also with the oldest supported qemu version.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the lookup of the corresponding QMP schema used for validation of
QMP commands from 'testCompareXMLToArgvValidateSchema' to
testQemuGetRealCaps as an optional step.
This will simplify using QMP command validation in other tests which
will use testQemuGetRealCaps.
'testutilsqemuschema' module is now linked into 'test_utils_qemu' as it
contains no monitor-specific code itself and after this patch it's
referenced directly from that module.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The last tests using it were refactored to use real capabilities and no
new tests should ever use it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rather than using fake data and faking the host use the newly introduced
support for test variants to test the OSX HVF qemu version with real
data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rather than using fake data and faking the host use the newly introduced
support for test variants to test the OSX HVF qemu version with real
data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The input is identical to that of the existing
firmware-auto-efi-aarch64 test, but in this case we want to
cover the scenario in which that input is used to define a new
domain rather than loading the definition of an existing domain
from disk.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
libvirt 8.6.0 introduced these checks and very clearly delineated
two possible firmware selection scenarios: manual firmware
selection, where the user is responsible for providing all
information, and firmware autoselection, where a list of desired
features is provided and everything else is handled by libvirt.
In the interest of maintaining the clear separation between these
two scenarios, setting most attributes when firmware autoselection
is active will result in the configuration being rejected.
This works fine, but is unnecessarily restrictive: in most cases,
the additional information that the user has provided matches
the information that libvirt would have discovered on its own by
looking at firmware descriptors, and asking the user to scrub it
from the XML only result in pointless friction.
Remove these checks entirely.
Unsurprisingly, this results in a few test cases that were
rejected until now to suddenly start working and producing
sensible results.
The firmware-auto-efi-loader-path-nonstandard test case is
notable: while we can now enable the xml2xml part of the test,
the xml2argv part is still failing, although in a slightly
different way. This is expected: since the firmware binary is a
non-standard one, libvirt is unable to figure out the missing
information from a firmware descriptor, and the configuration
is still ultimately an invalid one. However, if we were to find
such a configuration on disk at daemon startup, we would not
ignore it completely and instead would offer the user a chance
to fix it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
These cover the same scenarios as the matching test cases for
autoselection.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This is identical to the existing
firmware-auto-efi-loader-path-nonstandard test case, but uses
a standard firmware path.
Right now the two test cases behave identically, but that's
going to change in the future.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This unifies the naming between the manual and automatic
selection cases, clarifies the contents of the tests and makes
room for more tests being added in the future.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The newly added luks-any rbd encryption format in qemu
allows for opening both LUKS and LUKS2 encryption formats.
This commit enables libvirt uses to use this wildcard format.
Signed-off-by: Or Ozeri <oro@il.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This commit enables libvirt users to use layered encryption
of RBD images, using the librbd encryption engine.
This allows opening of an encrypted cloned image
whose parent is encrypted with a possibly different encryption key.
To open such images, multiple encryption secrets are expected
to be defined under the encryption XML tag.
Signed-off-by: Or Ozeri <oro@il.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
While no part of cmd line building process currently depends on a
host NUMA configuration, this will change soon. Use freshly
changed virnumamock from qemuxml2argvtest and make the mock read
NUMA data from vircaps2xmldata which seems to have the most rich
NUMA configuration.
This also means, we have to start building virnumamock
unconditionally. But this is not a problem, since nothing inside
of the mock relies on Linux specificity. The whole mock is merely
just reading files and parsing them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Commit 54fa1b44af ("conf: Add loadparm boot option for a boot device")
added the ability to specify a loadparm parameter on a <boot/> tag, while
commit 29ba41c2d4 ("qemu: Add loadparm to qemu command line string")
added that value to the QEMU "-machine" command line parameters.
Unfortunately, the latter commit only looked at disks and network
devices for boot information, even though anything with
VIR_DOMAIN_DEF_FORMAT_ALLOW_BOOT could potentially have this tag.
In practice, a <hostdev> tag pointing to a passthrough (SCSI or DASD)
disk device can be used in this way, which means the loadparm is
accepted, but not given to QEMU.
Correct this, and add some XML/argv tests.
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This can improve performance for some guests since it reduces copying of
display data between host and guest. Requires udmabuf on the host.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function doesn't set any capability and we don't want to add
arch-dependent always-peresent capabilities in the future.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU_CAPS_AES_KEY_WRAP, QEMU_CAPS_DEA_KEY_WRAP and QEMU_CAPS_LOADPARM
are always asserted via virQEMUCapsInitQMPBasicArch thus don't need to
be explicitly enabled by tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
testUpdateQEMUCaps calls virQEMUCapsInitQMPBasicArch which already sets
it. Purge the capability from the testing code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'qemu-system-aarch64' is superset of the soon to be deprecated
'qemu-system-arm' binary. We can move over all of our fake-caps tests to
real caps on aarch64.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We always assert the flag for aarch64 qemus and in qemu the 'aarch64'
cpu property doesn't seem to be optional.
Remove checks and remove impossible test case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert the 'ppc-dtb' and 'ppce500-serial' to use real capabilities
albeit captured from a non-native machine. Thus the XML needs to be
converted to use virt type 'qemu'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Preserve testing of the MMIO use case in case when GPEX is complied out
of qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert the only outstanding test case for a 'sparc' machine to modern
test infrastructure.
'sparc' machine type also needs to be added to the list of supported
arches in testQemuGetLatestCaps.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Make callers use virFileCacheClear to clear the cache before populating
it rather than trying to overwrite what's in it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use x86_64 emulator and machine and remove the nocaps version of the
test.
Fixes: 80a37e96a9
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
None of these settings is specific to the xml2argv test. Moving
them to the common code ensures the behavior of the QEMU driver
is consistent across all QEMU tests.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Creating a privileged config ensures these are already set
correctly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Most test programs were already doing this, and moving it to
the common code ensures we see consistent behavior across all
QEMU tests.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
These are intended to be used for just a few specific tests,
but since we don't always free them up afterwards they could
end up accidentally affecting subsequent tests as well.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Follow the example of other similar settings and only enable it
for the few test cases that are actually about the specific
functionality, disabling it immediately afterwards.
A few test cases that were completely unrelated to SPICE TLS no
longer see the effects of having the feature enabled.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Just like TLSx509certdirs, these can be set throughout the
lifetime of the test program.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The various TLSx509certdirs can be set throughout the lifetime
of the test program without issue.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Use latest caps for the tests even though the original test case didn't
need any capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use DO_TEST_CAPS_LATEST for cputune-numatune, cputune-zero-shares,
cputune, and vcpu-placement-static cases. Do the necessary tweaks to
work with actual data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use DO_TEST_CAPS_LATEST for the basic tests. The emulator needed to be
tweaked to work with the real caps data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'iothreads-disk' covers everything that 'iothreads' did in addition to
actually using the iothread.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All supported QEMU versions now support iothreads thus upcoming patches
will be removing the capability checks. Remove the 'iothreads-nocap'
case which will become invalid.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Instead of having each test manually initialize and cleanup
its own fakerootdir, do that as part of the common test
initialization logic in virTestMain().
In most cases we can simply drop the relevant code from the
test program, but scsihosttest uses the value of fakerootdir
as a starting point to build another path, so we need to do
things slightly differently. In order to keep things working,
we retrieve the value from the LIBVIRT_FAKE_ROOT_DIR
environment variable, same as all the mock libraries are
already doing.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Most replacements are completely straightforward but
vircgrouptest requires slightly different handling because,
instead of initializing a single fakerootdir at the start of
the test program and cleaning it up at the end, it creates
multiple different ones one after the other.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
These cover various scenarios related to firmware formats,
specifically ensuring that all the ways in which the user can
ask for a non-default format to be used work correctly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
At the moment, if SMM is explicitly disabled in the domain XML
but a firmware descriptor that requires SMM to be enabled has
the highest priority and otherwise matches the requirements,
we pick that firmware only to error out later, when the domain
is started.
A better approach is to take into account the fact that SMM is
disabled while performing autoselection, and ignore all
descriptors that advertise the requires-smm feature.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
These cover scenarios such as using the new, more verbose
format of the <nvram> element to point to a local path, mixing
firmware autoselection with non-local NVRAM files, and
explicitly disabling SMM when using firmware autoselection.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This is already the case for the vast majority, but a few are
using explicit capabilities lists.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
QEMU's "reconnect" option of "-netdev stream" tells QEMU to
periodically (period is given in seconds as an argument to the option)
attempt to reconnect to the same passt socket to which it had
originally connected to. This is useful in cases where the passt
process terminates, and libvirtd starts a new passt process in its
place (which doesn't happen yet, but will happen automatically after
an upcoming patch in this series).
Since there is no real hueristic for determining the "best" value of
the reconnect interval, rather than clutter up config with a knob that
nobody knows how to properly twiddle, we just set the reconnect timer
to 5 seconds.
"-netdev stream" first appeared in QEMU 7.2.0, but the reconnect
option won't be available until QEMU 8.0.0, so we need to check QEMU
capabilities just in case someone is using QEMU 7.2.0 (and thus can
support passt backend, but not reconnect)
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This is already possible with qemu, and actually already happening with
q35 machines and a specified watchdog since q35 already includes a
watchdog we do not include in the XML. In order to express such
posibility multiple watchdogs need to be supported.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Support virtio-crypto device, also support cryptodev types:
- builtin
- lkcf
Finally, we can launch a VM(QEMU) with one or more crypto devices by
libvirt.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This consists of (1) adding the necessary args to the qemu commandline
netdev option, and (2) starting a passt process prior to starting
qemu, and making sure that it is terminated when it's no longer
needed. Under normal circumstances, passt will terminate itself as
soon as qemu closes its socket, but in case of some error where qemu
is never started, or fails to startup completely, we need to terminate
passt manually.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Enable the qemuxml2xml variant and add output data for qemuxml2argvtest.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Introduce a new argument type for testQemuInfoSetArgs named ARG_FD_GROUP
which allows users to instantiate tests with populated FD passing hash
table.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Up until commit 629282d884, using mode=restrictive caused
virNumaSetupMemoryPolicy() to be called from qemuProcessHook(),
and that in turn resulted in virNumaNodesetIsAvailable() being
called and the nodeset being validated.
After that change, the only validation for the nodeset is the one
happening in qemuBuildMemoryBackendProps(), which is skipped when
using mode=restrictive.
Make sure virNumaNodesetIsAvailable() is called whenever a
nodeset has been provided by the user, regardless of the mode.
https://bugzilla.redhat.com/show_bug.cgi?id=2156289
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The one for mode=strict fails, as expected, while the one for
mode=restrictive currently doesn't even though it should. The
next commit will address the issue.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
According to the result parsing from xml, add the argument of
SGX EPC memory backend into QEMU command line.
$ qemu-system-x86_64 \
...... \
-object '{"qom-type":"memory-backend-epc","id":"memepc0","prealloc":true,"size":67108864,"host-nodes":[0,1],"policy":"bind"}' \
-object '{"qom-type":"memory-backend-epc","id":"memepc1","prealloc":true,"size":16777216,"host-nodes":[2,3],"policy":"bind"}' \
-machine sgx-epc.0.memdev=memepc0,sgx-epc.0.node=0,sgx-epc.1.memdev=memepc1,sgx-epc.1.node=1
Signed-off-by: Lin Yang <lin.a.yang@intel.com>
Signed-off-by: Haibin Huang <haibin.huang@intel.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Introduced in QEMU's commit of v4.2.0-rc0~23^2~4 the .failover
attribute of virtio-net device is always available for all QEMU
versions we support (4.2.0, currently). Therefore, we can assume
the capability is always set and thus doesn't need to be checked
for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v2.10.0-rc0~95^2~20 the
.tx_queue_size attribute of virtio-net device is always available
for all QEMU versions we support (4.2.0, currently). Therefore,
we can assume the capability is always set and thus doesn't need
to be checked for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v2.8.0-rc0~116^2~26 the
.rx_queue_size attribute of virtio-net device is always available
for all QEMU versions we support (4.2.0, currently). Therefore,
we can assume the capability is always set and thus doesn't need
to be checked for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v3.0.0-rc0~124^2~1 the
set-numa-node command is always available for all QEMU versions
we support (4.2.0, currently). Therefore, we can assume the
capability is always set and thus doesn't need to be checked for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v2.1.0-rc0~41^2~26 only for Linux,
and later in v3.1.0-rc0~71^2~10 for all POSIX, the
memory-backend-file is going to be present for all QEMU versions
we support (4.2.0, currently). Therefore, we can assume the
capability is always set and thus doesn't need to be checked for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in QEMU's commit of v2.1.0-rc0~41^2~104 the
memory-backend-ram is going to be present for all QEMU versions
we support (4.2.0, currently). Therefore, we can assume the
capability is always set and thus doesn't need to be checked for.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The aim of this test case it to make sure we error out when
QEMU_CAPS_OBJECT_MEMORY_RAM is missing. Well, it's never going to
be missing. Drop the test case.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently, we have maybe a dozen tests for hugepages related
stuff in qemuxml2argvtest. In all cases DO_TEST() is used, which
means we have to enumerate all capabilities needed (though, it's
usually just QEMU_CAPS_OBJECT_MEMORY_RAM and
QEMU_CAPS_OBJECT_MEMORY_FILE, exceptionally
QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD too).
Instead of deleting the caps flags one-by-one, just switch the
tests to use DO_CAPS_LATEST().
The qemuxml2xmltest will undergo similar treatment in next
commit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The removal of the special internal flag for '-netdev' validatition now
allows us to use the same virCommand object for validation of the
schema.
Pass it into the validator instead of re-parsing and re-generating
everything.
This improved the runtime of qemuxml2argvtest by ~25% on my box.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The qemuxml2argvtest pseries-feature parse failure tests uses a symlink
to the pseries-features.xml test domain and control which feature it is
supposed to fail by excluding it from the capabilities list. The
advantage of this approach is that the same XML can be used in multiple
tests.
One downside is that any new pseries capability must be declared in all
existent tests, otherwise all other tests can break if this new
capability happens to be validated early in qemu_validate.c. Any new
parse_error test must declare all other existent capabilities.
Another downside is the fact that we're testing fairly improbable
scenarios: all pseries capabilities being tested here were introduced by
the same QEMU version, 4.2.0, at least as far as libvirt is aware of.
This means that it's no possible to have a scenario where, for example,
ccf-assist is not present but cfpc is. And last, but not the least, it's
getting in the way of our effort to convert all pseries tests to not use
explicit capabilities.
Changing all these tests to use DO_TEST_PARSE_ERROR_NOCAPS() will allow
us to test exactly what we want to test, which is the parse error given
for each feature if the binary does not have support for it. The XML
being used for each test can be simplified to just declare a single
feature. In the end we'll end up with more XML lines, but less
complexity inside qemuxml2argvtest.c.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Eliminate most of the pseries tests that are using explicit qemu caps
instead of CAPS_LATEST. The remaining tests will be handled in the next
patch.
The changes made are trivial: rename the .args/.err files to
ppc64-latest.(args/err) and do the required changes to match the newest
capabilities.
A notable expection were tests pseries-console-native,
pseries-serial-compat and pseries-serial+console-native. These are
aliases of the pseries-serial-native tests. In this case we needed to
re-create the symlink accordingly.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Don't validate the root node and don't allocate a private XPath context
when virXMLParse can do that internally.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The generic helper also has helper code to validate the root element and
create an XPath context. Many places in the code duplicate code for
doing these operations.
Extend the helper to provide all arguments and fix all callers.
In many cases this patch refactors the passing of the 'validate'
field into a separate variable to avoid quirky looking arguments.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in libvirt by:
commit f245a9791c
qemu: introduce capability for virtual-css-bridge
Which mentions that its support was in QEMU 2.7.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This capability was introduced by libvirt commit:
commit 263e65fd20
qemu: introduce vfio-ccw capability
It probes for the cssid-unrestricted property of
virtual-css-bridge, which was introduced in QEMU v2.12 by:
commit 99577c492fb2916165ed9bc215f058877f0a4106
s390x/css: unrestrict cssids
Since we bumped the minimum QEMU version to 4.2.0, assume
this property is always present.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Among the usual changes, this puts the virtio memballoon on the CCW bus.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Besides the -cpu host, The host-phys-bits=on applies to custom or max
cpu model, So the host-passthrough validation check is unnecessary for
maxphysaddr with mode='passthrough'.
Signed-off-by: Lin Ma <lma@suse.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Added by QEMU commit:
commit 74b3e46630446568aecb0be1c77c4875d7a52f6d
Author: Jason Wang <jasowang@redhat.com>
CommitDate: 2019-10-25 07:46:22 -0400
virtio: add property to enable packed virtqueue
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Reviewed-by: Jens Freimann <jfreimann@redhat.com>
Message-Id: <20191025083527.30803-9-eperezma@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
git describe: v4.1.0-1780-g74b3e46630 contains: v4.2.0-rc0~32^2~17
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Introduced by QEMU commit 0846e6359c407e372f446723b8b7b09ac20d0f03
released in QEMU 1.3.0
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
As noted by the comments the only difference was the qemu capabilities
asserted. Now that we use only real caps for this test case it makes no
sense to have two copies.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Turn them into DO_TEST_CAPS_VER bound to qemu-4.2 to show the minimum
amount of change. We already have DO_TEST_CAPS_LATEST versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Further patches will try to remove QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY,
so add few more modern tests before doing that.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Switch from QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY to
QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL as it has no impact on the test
output.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced back in 2013 by QEMU commit:
commit 398489018183d613306ab022653552247d93919f
pc: limit 64 bit hole to 2G by default
Released in 1.6.0
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This is needed to ensure the environment variables that we need
for the test program itself, specifically to load mock libraries,
do not interfere with any command that gets invoked by it, either
directly or indirectly. We already perform the same cleanup step
for LD_* variables.
This makes the test failures
error : virCommandWait:2752 : internal error: Child process
(/usr/libexec/qemu/vhost-user/test-vhost-user-gpu --print-capabilities)
unexpected fatal signal 6: dyld[8896]: symbol not found in flat
namespace '_virQEMUCapsGet'
error : qemuVhostUserFillDomainGPU:394 : operation failed: Unable to
find a satisfying vhost-user-gpu
that were showing up on macOS 12 go away.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced back in 2010 by QEMU commit:
commit a697a334b3c4d3250e6420f5d38550ea10eb5319
virtio-net: Introduce a new bottom half packet TX
Released in QEMU 0.14.0
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Modernize the tests as they mostly care that the aliases are properly
propagated to qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code no longer uses the capability so the tests don't need to assert
it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Minimum qemu version is going to be bumped to qemu-4.2. Upgrading the
version of these tests doesn't make sense as the host cpu in the real
capabilities doesn't support the features the tests are attempting to
test.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Minimum qemu will be bumped to 4.2 so this test no longer makes sense.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Minimum qemu will be bumped to 4.2 so remove the older test cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Starting from qemu-4.0 a new device model name is used instead of the
'disable_*' props. Since we are going to bump to qemu-4.2 as minimum
this test can be removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Minimum qemu version will be bumped to qemu-4.2 so we no longer need to
care about configuring audiodevs via the environment variables.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will bump minimum supported qemu version to 4.2 which
will use '-blockdev' with qemu so we can drop all the old test cases for
pre-blockdev configs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will bump minimum qemu version to 4.2. In this case we
the 'latest' case is sufficient as with qemu-4.2 we already behave as
upstream ('qemu64' cpu is used instead of 'qemu32').
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This patch maps /domain/cpu/maxphysaddr into -cpu parameters:
- <maxphysaddr mode='passthrough'/> becomes host-phys-bits=on
- <maxphysaddr mode='emualte' bits='42'/> becomes phys-bits=42
Passthrough mode can only be used if the chosen CPU model is
'host-passthrough'. Also validate that an explicitly specified
bits value does not exceed the physical address bits on the host.
The feature is available since QEMU 2.7.0.
Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that we have all the machinery needed, we can introduce two
simple test cases:
1) only TPM 1.2 is supported, but TPM 2.0 was requested in domain XML,
2) only TPM 2.0 is supported, but TPM 1.2 was requested in domain XML.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Almost all of memory models we currently support allow setting
virDomainMemoryDef::targetNode so that the memory module is
associated with given guest NUMA node. And we do have a check
whether the requested node is within bounds, but it's executed
only when building QEMU's cmd line. Move it into validation
phase.
While this commit is moving the validation to a place that does
not validate all the possible code paths, it's okay, because only
the explicit memory device has user-configurable target node
which could break the assumption.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
So far, we are testing memory-hotplug-dimm-addr against a set of
explicitly listed capabilities. While this works, lets switch it
to DO_TEST_CAPS_LATEST() so that the latest capabilities are
used. This in turn means, we have to update the <emulator/>
because the latest capabilities don't contain caps for
qemu-system-i386.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When the <loader stateless='yes'/> attribute is set, the QEMU driver
needs to do three things
- Avoid looking for an NVRAM template
- Avoid auto-populating an <nvram/> path
- Find firmware descriptors with mode=stateless instead of mode=split
Note, the first thing happens automatically when we solve the second
thing.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Normally when an UEFI firmware is marked as read-only, an associated
NVRAM file will be created. Some builds of UEFI firmware, however, wish
to remain stateless and so will be read-only, but never have any NVRAM
file. To represent this concept a 'stateless' tristate bool attribute
is introduced on the <loader/> element.
There are rather a large number of permutations to consider.
With default firmware selection
* <os/>
=> Historic default, no change
* <os>
<loader stateless='yes'/>
</os>
=> Explicit version of historic default, no change
* <os>
<loader stateless='no'/>
</os>
=> Invalid, bios is always stateless
With manual legacy BIOS selection
* <os>
<loader>/path/to/seabios</loader>
...
</os>
=> Historic default, no change
* <os>
<loader stateless='yes'>/path/to/seabios</loader>
...
</os>
=> Explicit version of historic default, no change
* <os>
<loader stateless='no'>/path/to/seabios</loader>
...
</os>
=> Invalid, bios is always stateless
With manual UEFI selection
* <os>
<loader type='pflash'>/path/to/edk2</loader>
...
</os>
=> Historic default, no change
* <os>
<loader type='pflash' stateless='yes'>/path/to/edk2</loader>
...
</os>
=> Skip auto-filling NVRAM / template
* <os>
<loader type='pflash' stateless='no'>/path/to/edk2</loader>
...
</os>
=> Explicit version of historic default, no change
With automatic firmware selection
* <os firmware='bios'/>
=> Historic default, no change
* <os firmware='bios'>
<loader stateless='yes'/>
</os>
=> Explicit version of historic default, no change
* <os firmware='bios'>
<loader stateless='no'/>
</os>
=> Invalid, bios is always stateless
* <os firmware='uefi'/>
=> Historic default, no change
* <os firmware='uefi'>
<loader stateless='yes'/>
</os>
=> Skip auto-filling NVRAM / template
* <os firmware='uefi'>
<loader stateless='no'/>
</os>
=> Explicit version of historic default, no change
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
These wrapper functions were used to adapt the virObjectUnref() function
signature for different callbacks. But in commit 0d184072, the
virObjectUnref() function was changed to return a void instead of a
bool, so these adapters are no longer necessary.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Currently, we have bunch of PCI/USB tests cases for
qemuxml2argvtest and qemuxml2xmltest but all of them run without
any capabilities. This makes is needlessly complicated when
trying to extend them. Switch to DO_TEST_CAPS_LATEST().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The cpu commandline is identical with the '-latest' version so there's
no need for a separate case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Make it obvious that the fake cpu does not apply to the test cases based
on real capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test was showing that the 'blockdev' capability is properly added
although we didn't detect it yet. Unfortunately this test can't be
carried over once we bump minimum qemu version to qemu-4.2.
Make the test case future-proof by removing the qemu-4.0.0 version which
would become pointless and use only already deprecated capability flags
so that the test output does not change.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The tested net device has the same syntax with latest qemu so there's no
need to have a version-locked test for it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The cpu feature formatting doesn't change between the versions thus we
can just keep the '-latest' versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The tested feature doesn't change across versions so we can use the
modern testing infrastructure.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The version-locked version of the test data is identical to the 'latest'
version so we can remove them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Prior to qemu-3.2 we'd have to disable the 'pconfig' feature explicitly
which is no longer needed with new qemu. Remove the version locked to
qemu-3.1 as the 'latest' case sufficiently handles what we want to test.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Generally speaking, when firmware autoselection is in use we
don't want any information to be provided manually. There are
two exceptions:
* we still want the path to the NVRAM file to be customizable;
* using <loader secure='yes'/> was how you would ask for a
firmware that implements the Secure Boot feature in the
original approach to firmware autoselection, so we want to
keep that working.
Anything else should result in a descriptive error.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/327
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This combination doesn't make sense and so the firmware
autoselection logic will not be able to find a suitable firmware,
but it's more user-friendly to report a detailed error upfront.
Note that this check would ideally happen in the validate phase,
but if we moved it there we would no longer be able to
automatically enable secure-boot when enrolled-keys=yes. Since
the combination never resulted in a working configuration, the
chances of this causing real-world VMs to disappear are
extremely low.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Note that some of these new tests are displaying incorrect or
suboptimal behavior. When we address those in upcoming patches,
this will be highlighted by changes in the test data.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa