Commit Graph

10 Commits

Author SHA1 Message Date
Michal Privoznik
436dcf0b74 qemu: Add AAVMF to the list of known UEFIs
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: Michal Privoznik <mprivozn@redhat.com>
2015-01-29 15:20:47 +01:00
Michal Privoznik
bc03a23149 qemu: Allow UEFI paths to be specified at compile time
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: Michal Privoznik <mprivozn@redhat.com>
2015-01-29 15:20:42 +01:00
Michal Privoznik
c6ec7c6b0b tests: Check for virQEMUDriverConfigNew return value
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: Michal Privoznik <mprivozn@redhat.com>
2015-01-26 17:34:33 +01:00
Roman Bogorodskiy
3b3947ea37 Fix build in qemu_capabilities
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.
2014-09-18 13:37:12 +04:00
Michal Privoznik
b3f42da6b7 domaincapstest: Run cleanly on systems missing OVMF firmware
As of f05b6a918e 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: Michal Privoznik <mprivozn@redhat.com>
2014-09-17 17:42:47 +02:00
Michal Privoznik
f05b6a918e domaincaps: Expose UEFI binary path, if it exists
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: Michal Privoznik <mprivozn@redhat.com>
2014-09-17 16:29:49 +02:00
Michal Privoznik
2b2e4a7acf qemu_capabilities: Change virQEMUCapsFillDomainCaps signature
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: Michal Privoznik <mprivozn@redhat.com>
2014-09-17 16:27:06 +02:00
Michal Privoznik
4f76621c0e domaincaps: Expose UEFI capability
As of 542899168c 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: Michal Privoznik <mprivozn@redhat.com>
2014-09-17 09:42:33 +02:00
Michal Privoznik
94e3f23e8a qemu: Implement virConnectGetDomainCapabilities
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: Michal Privoznik <mprivozn@redhat.com>
2014-07-03 12:22:38 +02:00
Michal Privoznik
614581f32b Introduce domain_capabilities
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: Michal Privoznik <mprivozn@redhat.com>
2014-07-03 12:22:37 +02:00