The patch adds <cpu> element to domain capabilities XML:

    <cpu>
        <mode name='host-passthrough' supported='yes'/>
        <mode name='host-model' supported='yes'/>
        <mode name='custom' supported='yes'>
            <model>Broadwell</model>
            <model>Broadwell-noTSX</model>
            ...
        </mode>
    </cpu>

Applications can use it to inspect what CPU configuration modes are
supported for a specific combination of domain type, emulator binary,
guest architecture and machine type.
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

Most of the time, the <dt> tag is used when providing
documentation for a symbol; enclose symbols in <code> tags to
style them appropriately.

Well, since the link to the virConnectGetDomainCapabilities API is in
<pre/> section we must take special care about the spaces around the
link.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Acked-by: NLaszlo Ersek <lersek@redhat.com>

Since libvirt.h was split into multiple files and similarly
docs/libvirt-libvirt.html, docs/hvsupport.html have bad hyperlinks.  The
same happens for all the html.in files that used <code class='docref'>
tag, because page.xsl has no idea where to point the link that's found.
Signed-off-by: NMartin Kletzander <mkletzan@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>

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>

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>