In a few places we still use the good old:
sizeof(var) / sizeof(var[0])
sizeof(var) / sizeof(int)
The G_N_ELEMENTS() macro is preferred though. In a few places we
don't link with glib, so provide the macro definition.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
libxl added support for specifying custom firmware paths long ago. The
functionality exists in all Xen version supported by libvirt. This patch
adds support for user-specified efi firmware paths in the libxl driver.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently it's only possible to set this parameter during domain
creation via QEMU commandline passthrough feature.
With the new delay attribute it's also possible to set this
parameter if you want to attach a new NBD disk
using "virsh attach-device domain device.xml" e.g.:
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol='nbd' name='foo'>
<host name='example.org' port='6000'/>
<reconnect delay='10'/>
</source>
<target dev='vdb' bus='virtio'/>
</disk>
Signed-off-by: Christian Nautze <christian.nautze@exoscale.ch>
Reviewed-by: Michal Privoznik <mprivozn@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>
Capability to determine whether this qemu supports the 'blob' option for
virtio-gpu.
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>
The capability is based on a platform check rather than what given qemu
supports.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit 24cc9cda82 switched over to use -machine hpet, but one of the
steps it did was to clear the QEMU_CAPS_NO_HPET capability.
The validation check still uses the old capability though which means
that for configs which would explicitly enable HPET we'd report an error.
Since HPET is an x86(_64) platform specific device, convert the
validation check to an architecture check as all supported qemu versions
actually support it.
Modify a test case to request HPET to catch posible future problems.
Fixes: 24cc9cda82
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All tests were converted to use real capabilities so there's no need to
support the infrastructure for fake tests.
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>
All tests were converted to use real capabilities so there's no need to
support the infrastructure for fake tests.
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>
The data are obtained from a x86_64 machine thus don't really represent
physical hardware, but it's better than nothing.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All tests were converted to use real capabilities so there's no need to
support the infrastructure for fake tests.
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>
In certain cases we want to use as-real capabilities as possible but
that doesn't allow testing certain fallback scenarios of features that
can be complied out of QEMU.
ARG_QEMU_CAPS_DEL can be used similarly to ARG_QEMU_CAPS but the flag
arguments are actually masked out of the resulting caps.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rather that populate a virQEMUCaps object we now populate a bitmap with
the fake capabilities and transfer it into the virQEMUCaps later.
This unifies the code paths between the fully fake caps tests and real
caps + fake flags.
Also the same approach will be used in upcomming patch to add
possibility to mask out flags from real capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There's just one case when we're populating the cache with empty caps so
that can allocate a dummy virQEMUCaps object rather than having the
logic inside qemuTestCapsCacheInsertImpl.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Make all callers always pass a valid pointer which in turn allows us to
remove return value check from the callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The allocation of the object itself can't fail. What can fail is the
creation of the class on a programming error. Rather than punting the
error up the stack abort() directly on the first occurence as the error
can't be fixed during runtime.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All tests were converted to use real capabilities so there's no need to
support the infrastructure for fake tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Both 'kvm_machines' and 'qemu_machines' now have the same members so we
can simply drop kvm_machines.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All tests were converted to use real capabilities so there's no need to
support the infrastructure for fake tests.
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>
Real capabilities populate the binary name, while fake don't. We can
directly insert the capabilities using the real binary name.
This will allow to remove 'qemu_emulators' entries once all tests are
converted to real capabilties.
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>
Integrate the two special cases used for schema testing into the more
useful qemuxml2argvtest, whose input data is still tested against the
schema.
Add also a xml output variant.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The schema tested by removed test cases is tested by other, more useful,
test cases:
- 'maxMemory'
- qemuxmlargvdata/memory-hotplug*
- 'backingChains'
- qemuxmlargvdata/disk-backing-chains*
- 'timers'
- qemuxml2argvdata/kvm-pit-delay.xml
- qemuxml2argvdata/clock-catchup.xml
- 'qemu-simple-description-title.xml'
- 'qemuxml2argvdata/minimal.xml
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Turns out that those overrides I recently removed where actually
there for a reason, and there was a motivation behind creating
the driver config as unprivileged too O:-)
Until a solution that can both ensure predictable output and
avoid code duplication is developed, go back to the previous
approach.
Fixes: 2f56f69f7f ("tests: Create privileged config for QEMU driver")
Fixes: 0f49b6cc6b ("tests: Drop no longer necessary overrides")
Fixes: 0b464cd84f ("tests: Drop more QEMU driver config overrides")
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
These are allegedly necessary to keep the output consistent,
but now that we're using a privileged config for the driver we
get the desired behavior out of the box, and as a bonus the
paths match what you would actually see on a regular host.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
We use standard paths for almost everything else.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
For almost all directories, the value we set matches the one
a standard deployment would use, but in a couple of cases they
deviate from that. Keep things consistent.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@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>
