Commit Graph

12 Commits

Author SHA1 Message Date
Jiri Denemark
9ac9b039c4 domaincapstest: Give better names to test data files
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-05-16 10:37:29 +02:00
Cole Robinson
5ed235c68f domaincaps: Report video modelType
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
2016-05-09 16:05:31 -04:00
Cole Robinson
6da27ad1b5 domaincaps: Report graphics type enum
Requires adding the plumbing for <device><graphics>
Wire it up for qemu too
2016-05-09 16:05:31 -04:00
Jiri Denemark
3957dd1acf domaincapstest: Add tests for QEMU 2.6
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-05-06 10:38:31 +02:00
Jiri Denemark
f51e8a6282 domaincapstest: Use default machine type
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-05-06 10:38:30 +02:00
Jiri Denemark
55b1073451 qemucapabilitiestest: Test all capabilities
Enhance the test to cover all capabilities we probe for rather than
testing the flags only.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-05-06 10:35:32 +02:00
Andrea Bolognani
4e2d82f72b conf: Expose GIC capabilities
Add information about GIC capabilities to virDomainCaps and update
the formatter to include them in the XML output.
2016-04-20 12:52:41 +02:00
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
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
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