Commit Graph

114 Commits

Author SHA1 Message Date
Jiri Denemark
b3fd95e368 qemu: Add RDMA migration capabilities 2014-09-23 08:11:49 +02:00
Pavel Hrdina
da7799d879 Move the FIPS detection from capabilities
We are not detecting the presence of FIPS from QEMU, but from procfs and
that means it's not QEMU capability. It was decided that we will pass
this flag to QEMU even if it's not supported by old QEMU binaries.

This patch also reverts changes done by commit a21cfb0f to
qemucapabilitestest and implements a new test case in qemuxml2argvtest.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1135431

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2014-09-19 09:08:23 +02:00
Michal Privoznik
3ecb9e7631 tests: Move qemu caps XML parsing into shared unit
Later on, we the qemu capabilities XML parsing code may come handy so
instead of duplicating the code make the already existing one shared.
By the same time, make the function accept file name instead of XML
document stored already in memory.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-07-03 12:22:37 +02:00
Ján Tomko
2dcdb7f654 Indent top-level labels by one space in tests/ 2014-03-25 14:58:41 +01:00
Eric Blake
a21cfb0f48 qemu: ask for -enable-fips when FIPS is required
On a system that is enforcing FIPS, most libraries honor the
current mode by default.  Qemu, on the other hand, refused to
honor FIPS mode unless you add the '-enable-fips' command
line option; worse, this option is not discoverable via QMP,
and is only present on binaries built for Linux.  So, if we
detect FIPS mode, then we unconditionally ask for FIPS; either
qemu is new enough to have the option and then correctly
cripple insecure VNC passwords, or it is so old that we are
correctly avoiding a FIPS violation by preventing qemu from
starting.  Meanwhile, if we don't detect FIPS mode, then
omitting the argument is safe whether the qemu has the option
(but it would do nothing because FIPS is disabled) or whether
qemu lacks the option (including in the case where we are not
running on Linux).

The testsuite was a bit interesting: we don't want our test
to depend on whether it is being run in FIPS mode, so I had
to tweak things to set the capability bit outside of our
normal interaction with capability parsing.

This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1035474

* src/qemu/qemu_capabilities.h (QEMU_CAPS_ENABLE_FIPS): New bit.
* src/qemu/qemu_capabilities.c (virQEMUCapsInitQMP): Conditionally
set capability according to detection of FIPS mode.
* src/qemu/qemu_command.c (qemuBuildCommandLine): Use it.
* tests/qemucapabilitiestest.c (testQemuCaps): Conditionally set
capability to test expected output.
* tests/qemucapabilitiesdata/caps_1.2.2-1.caps: Update list.
* tests/qemucapabilitiesdata/caps_1.6.0-1.caps: Likewise.

Signed-off-by: Eric Blake <eblake@redhat.com>
2013-12-18 07:05:29 -07:00
Eric Blake
fb8613525d maint: avoid further typedef accidents
To make it easier to forbid future attempts at a confusing typedef
name ending in Ptr that isn't actually a pointer, insist that we
follow our preferred style of 'typedef foo *fooPtr'.

* cfg.mk (sc_forbid_const_pointer_typedef): Enforce consistent
style, to prevent issue fixed in previous storage patch.
* src/conf/capabilities.h (virCapsPtr): Fix offender.
* src/security/security_stack.c (virSecurityStackItemPtr):
Likewise.
* tests/qemucapabilitiestest.c (testQemuDataPtr): Likewise.

Signed-off-by: Eric Blake <eblake@redhat.com>
2013-10-30 17:02:12 -06:00
Eric Blake
b8984770dc maint: avoid 'const fooPtr' in tests
'const fooPtr' is the same as 'foo * const' (the pointer won't
change, but it's contents can).  But in general, if an interface
is trying to be const-correct, it should be using 'const foo *'
(the pointer is to data that can't be changed).

Fix up offenders in the testsuite.

* tests/cputest.c (cpuTestCompareXML): Use intended type.
* tests/qemucapabilitiestest.c (testQemuCaps): Likewise.
* tests/qemumonitorjsontest.c: Drop const.

Signed-off-by: Eric Blake <eblake@redhat.com>
2013-10-14 14:34:37 -06:00
Daniel P. Berrange
eee6eb666c Remove test case average timing
The test case average timing code has not been used by any test
case ever. Delete it to remove complexity.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-10-08 12:39:30 +01:00
Michal Privoznik
50c5818c0d qemucapabilitiesdata: Add qemu-1.6.50 data
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-10-03 15:52:06 +02:00
Michal Privoznik
3e17d7956f qemucapabilitiesdata: Add qemu-1.6.0 data
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-10-03 15:52:06 +02:00
Michal Privoznik
47674a2241 qemucapabilitiesdata: Add qemu-1.4.2 data
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-10-03 15:52:06 +02:00
Michal Privoznik
37819287f8 qemucapabilitiesdata: Add qemu-1.3.1 data
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-10-03 15:52:06 +02:00
Michal Privoznik
f44cea7374 qemucapabilitiesdata: Add qemu-1.2.2 data
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-10-03 15:52:06 +02:00
Michal Privoznik
63857eb4a0 tests: Introduce qemucapabilitiestest
This test is there to ensure that our capabilities detection code isn't
broken somehow.

How to gather test data:

Firstly, the data is split into two separate files. The former (with
suffix .replies) contains all the qemu replies. This is very fragile as
introducing a new device can mean yet another monitor command and hence
edit of this file in the future. But there's no better way of doing
this. To get this data simply turn on debug logs and copy all the
QEMU_MONITOR_IO_PROCESS lines. But be careful to not copy incomplete
ones (yeah, we report some incomplete lines too). Long story short, at
the libvirtd startup, a dummy qemu is spawn to get all the capabilities.

The latter (with suffix .caps) contains capabilities XML. Just start a
domain and copy the corresponding part from its state XML file.
Including <qemuCaps> tag.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-10-01 11:13:36 +02:00