The qemu limit and host limit both should be considered for
the domain vcpu max limits.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>

Commit 2a58ed0b added support for creating guests with USB
hostdevs. Commit fc21d106 later added support for hotplut of
USB hostdevs. Advertise support for USB hostdevs in the
domcapabilities.

In addition add the appropriate caps for USB support on
domaincapstest when libvirt is built on a Xen with
LIBXL_HAVE_PVUSB. Otherwise domaincapstest would fail i.e.
testing the wrong domain capabilities.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>

Add domain capabilities for PV and HVM domains.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

The virQEMUDriverConfig object contains lists of
loader:nvram pairs to advertise firmwares supported by
by the driver, and qemu_conf.c contains code to populate
the lists, all of which is useful for other drivers too.

To avoid code duplication, introduce a virFirmware object
to encapsulate firmware details and switch the qemu driver
to use it.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This function doesn't follow our convention of naming functions.

This function doesn't follow our convention of naming functions.

The qemu-1.6.50 is a beta before the new minor version, let's replace it with
the release qemu-1.7.0.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

They are shorter and most of the code requires the strings anyway.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Requires adding the plumbing for <device><video>
The value is <enum name='modelType'> to match the associated domain
XML of <video><model type='XXX'/>

Wire it up for qemu too

Requires adding the plumbing for <device><graphics>
Wire it up for qemu too

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The test was just a big mess passing callbacks and their data through
data for another callback.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The struct contains a single boolean field, 'supported':
the meaning of this field is too generic to be limited to
devices only, and in fact it's already being used for
other things like loaders and OSs.

Instead of trying to come up with a more generic name just
get rid of the struct altogether.

Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com>

Replaces a common pattern used in many test files

Well, even though users can pass the list of UEFI:NVRAM pairs at the
configure time, we may maintain the list of widely available UEFI
ourselves too. And as arm64 begin to rises, OVMF was ported there too.
With a slight name change - it's called AAVMF, with AAVMF_CODE.fd
being the UEFI firmware and AAVMF_VARS.fd being the NVRAM store file.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Up until now there are just two ways how to specify UEFI paths to
libvirt. The first one is editing qemu.conf, the other is editing
qemu_conf.c and recompile which is not that fancy. So, new
configure option is introduced: --with-loader-nvram which takes a
list of pairs of UEFI firmware and NVRAM store. This way, the
compiled in defaults can be passed during compile time without
need to change the code itself.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The function may return NULL if something went wrong. In some places
in the tests we are not checking the return value rather than
accessing the pointer directly resulting in SIGSEGV.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit f05b6a91 added virQEMUDriverConfigPtr argument to the
virQEMUCapsFillDomainCaps function and it uses forward declaration
of virQEMUDriverConfig and virQEMUDriverConfigPtr that casues clang
build to fail:

gmake[3]: Entering directory `/usr/home/novel/code/libvirt/src'
  CC       qemu/libvirt_driver_qemu_impl_la-qemu_capabilities.lo
In file included from qemu/qemu_capabilities.c:43:
In file included from qemu/qemu_hostdev.h:27:
qemu/qemu_conf.h:63:37: error: redefinition of typedef 'virQEMUDriverConfig'
is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct _virQEMUDriverConfig virQEMUDriverConfig;
                                    ^
qemu/qemu_capabilities.h:328:37: note: previous definition is here
typedef struct _virQEMUDriverConfig virQEMUDriverConfig;
                                    ^

Fix that by passing loader and nloader config attributes directly
instead of passing complete config.

As of f05b6a91 the test produces the list of paths that can
be passed to <loader/> and libvirt knows about them. However,
during the process of generating the list the paths are checked
for their presence. This may produce different results on
different systems.  Therefore, the path - if missing - is
added to pretend it's there.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Check to see if the UEFI binary mentioned in qemu.conf actually
exists, and if so expose it in domcapabilities like

<loader ...>
  <value>/path/to/ovmf</value>
</loader>

We introduce some generic domcaps infrastructure for handling
a dynamic list of string values, it may be of use for future bits.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Up till now the virQEMUCapsFillDomainCaps() was type of void as
there was no way for it to fail. This is, however, going to
change in the next commit.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

As of 54289916 we learned libvirt to use UEFI for domains.
However, management applications may firstly query if libvirt
supports it. And this is where virConnectGetDomainCapabilities()
API comes handy.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So far only information on disks and host devices are exposed in the
capabilities XML. Well, at least something. Even a new test is
introduced. The qemu capabilities are stolen from already existing
qemucapabilities test. There's one tricky point though. Functions that
checks host's KVM and VFIO capabilities, are impossible to mock
currently. So in the test, we are setting the capabilities by hand.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This new module holds and formats capabilities for emulator. If you
are about to create a new domain, you may want to know what is the
host or hypervisor capable of. To make sure we don't regress on the
XML, the formatting is not something left for each driver to
implement, rather there's general format function.

The domain capabilities is a lockable object (even though the locking
is not necessary yet) which uses reference counter.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>