libvirt currently always reports that USB is available as a bus subsystem
type when running "virsh domcapabilities". However, this is not always
true, for example the qemu-system-s390x binary normally never has support
for USB. Thus we should only report that USB is available if there is
also a USB host controller available where we can attach USB devices.
Reported-by: NSebastian Mitterle <smitterl@redhat.com>
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1759849Signed-off-by: NThomas Huth <thuth@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The qemu driver will obey <backingStore> when we support blockdev.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

In a follow-up commit, we will use the domain capabilities to validate
video device configurations, which means that we also need to make sure
that the domain capabilities include the "none" video device.
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>

Now that the only data we need for fully testing a QEMU binary is
the (version, arch) combo, we can stop providing that information
ourselves and instead rely on testQemuCapsIterate() automatically
picking up new input files as they are added to the repository,
the same way the qemucapabilities and qemucaps2xml tests already
behave.

Unsurprisingly, this change results in a bunch of extra output
files being created, significantly expanding our test coverage.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

The usual convention is to use ${foo}test.c for the test program
itself and either ${foo}data/ or ${foo}outdata/, depending on
whether it contains both input and output files or only the latter,
for the corresponding data directory.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

The KVM assignment was removed in qemu driver in previous commit.
Remove it from domaincapstest too which is hard coding it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

The model logic is taken from qemuDomainRNGDefValidate
Reviewed-by: NReviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

If a management application wants to use firmware auto selection
feature it can't currently know if the libvirtd it's talking to
support is or not. Moreover, it doesn't know which values that
are accepted for the @firmware attribute of <os/> when parsing
will allow successful start of the domain later, i.e. if the mgmt
application wants to use 'bios' whether there exists a FW
descriptor in the system that describes bios.

This commit then adds 'firmware' enum to <os/> element in
<domainCapabilities/> XML like this:

  <enum name='firmware'>
    <value>bios</value>
    <value>efi</value>
  </enum>

We can see both 'bios' and 'efi' listed which means that there
are descriptors for both found in the system (matched with the
machine type and architecture reported in the domain capabilities
earlier and not shown here).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Acked-by: NLaszlo Ersek <lersek@redhat.com>

This generates new XML like:

    <disk>
      <enum name='model'>
        <value>virtio</value>
        <value>virtio-transitional</value>
        <value>virtio-non-transitional</value>
      </enum>
    </disk>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

We only formatted the <sev> element when QEMU supported the feature when
in fact we should always format the element to make clear that libvirt
knows about the feature and the fact whether it is or isn't supported
depends on QEMU version, in other words if QEMU doesn't support the
feature we're going to format the following into the domain capabilities
XML:

<sev supported='no'/>

This patch also adjusts the RNG schema accordingly in order to reflect
the proposed change.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Report domaincaps <features><genid supported='yes'/> if the guest
config accepts <genid/> or <genid>$GUID</genid>.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
ACKed-by: NMichal Privoznik <mprivozn@redhat.com>

Report <features><vmcoreinfo supported='yes'/> if the guest config
accepts <features><vmcoreinfo state='on'/>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Add a path for UEFI VMs for AArch32 VMs, based on the path Debian is using.
libvirt is the de facto canonical location for defining where distros
should place these firmware images, so let's define this path here to try
and minimize distro fragmentation.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1441964Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Our documentation of the domain capabilities XML says that the fallback
attribute of a CPU model is used to indicate whether the CPU model was
detected by libvirt itself (fallback="allow") or by asking the
hypervisor (fallback="forbid"). We need to properly set
fallback="forbid" when CPU model comes from QEMU to match the
documentation.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When qmp query-cpu-model-expansion is available probe Qemu for its view of the
host model. In kvm environments this can provide a more complete view of the
host model because features supported by Qemu and Kvm can be considered.
Signed-off-by: NCollin L. Walling <walling@linux.vnet.ibm.com>
Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>

Tests domain capabilities on s390x using the Qemu 2.8 capabilities data.
Signed-off-by: NCollin L. Walling <walling@linux.vnet.ibm.com>
Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>