Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Add a capability check for IOThread polling (all were added at the
same time, so only one check is necessary).

Based on code originally posted by Pavel Hrdina <phrdina@redhat.com>
with the only changes to include the more recent QEMU releases.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
ACKed-by: NMichal Privoznik <mprivozn@redhat.com>

QEMU 3.1 should only expose the property if the host is actually
capable of creating hugetable-backed memfd. However, it may fail
at runtime depending on requested "hugetlbsize".
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Check availability of "-object memory-backend-memfd".
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

QEMU on s390 supports PCI multibus since forever.
Signed-off-by: NYi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Let's introduce zPCI capability.
Signed-off-by: NYi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Introduce vfio-ap capability.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NChris Venteicher <cventeic@redhat.com>

It was already available in 1.5.0, so we can assume it's
present and avoid checking for it at runtime.

This commit is best viewed with 'git show -w'.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

We already prefer them in capabilities, and domcapabilities
should be consistent with that.

This commit is best viewed with 'git show -w'.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

The new implementation contains less duplicated code and
is easier to extend.

This commit is best viewed with 'git show -w'.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

The latter is used throughout libvirt, so use it here as
well for consistency.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Now that we have reduced the number of sensible options down
to either the native QEMU binary or RHEL's qemu-kvm, we can
make virQEMUCapsInitGuest() a bit simpler.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Both Fedora's qemu-kvm and Debian's/Ubuntu's kvm are nothing
more than paper-thin wrappers around the native QEMU binary,
so we gain nothing by looking for them.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

We're only ever passing a single binary when calling this
function, so we can remove all code dealing with the
possibility of a second binary being specified.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

When the guest is native, we are currently looking at
potential KVM binaries regardless of whether or not we have
already located a QEMU binary suitable to run the guest.

This made sense back when KVM support was not part of QEMU
proper, but these days the KVM binaries are in most cases
just trivial wrapper scripts around the native QEMU binary
so it doesn't make sense to poke at them unless they're
the only binaries on the system, such as when running on
RHEL.

This will allow us to simplify both virQEMUCapsInitGuest()
and virQEMUCapsInitGuestFromBinary().
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

When running an armv7l guest on an aarch64 hosts, the
qemu-system-aarch64 binary should be our first choice instead
of qemu-system-arm since the former can take advantage of KVM
acceleration.

Move the special case to virQEMUCapsFindBinaryForArch() so
that it's handled along with all other cases rather than on
its own later on.

Doing so will also make further refactoring easier.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

virCapabilitiesAddGuestDomain() takes an optional binary
name: this is intended for cases where a certain domain
type can't use the default one registered for the guest
architecture, but has to use a special binary instead.

The current code, however, will pass 'binary' again when
'kvmbin' is not defined, which is unnecessary as 'binary'
has been registered as default earlier, and will result
in capabilities output such as

  <emulator>/usr/bin/qemu-system-x86_64</emulator>
  <domain type='qemu'/>
  <domain type='kvm'>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
  </domain>

with the second <emulator> element providing no additional
information.

Change it so that, when 'kvmbin' is not defined, NULL is
passed and so the default emulator will be used instead.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

The function performing the checks, rather than its callers,
should contain comments explaining the rationale behind said
checks.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

There seems to be no need to add the ignore_value wrapper or
caste with (void) to the unlink() calls, so let's just remove
them. I assume at one point in time Coverity complained. So,
let's just be consistent - those that care to check the return
status can and those that don't can just have the naked unlink.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

The file being present doesn't necessarily mean anything these
days, as it's created independently of whether the kvm module
has been loaded[1]; moreover, we're already gathering all the
information we need through QMP, so poking the filesystem at
all is entirely unnecessary.

[1] https://github.com/systemd/systemd/commit/d35d6249d5a7ed3228Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

This capability is documented as having one meaning (whether
KVM is enabled by default) but is actually assigned two other
meanings over its life: whether the query-kvm QMP command is
available at first, and later on whether KVM is usable / was
used during probing.

Since the query-kvm QMP command was available in 1.5.0, we
can avoid probing for it; additionally, we can simplify the
logic by setting the flag when it applies instead of initially
setting it and then clearing it when it doesn't.

The flag's description is also updated to reflect reality.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

A side effect of recent changes is that we would always try
to regenerate the capabilities cache for non-native QEMU
binaries based on /dev/kvm availability, which is of course
complete nonsense. Make sure that doesn't happen.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

It was already available in 1.5.0.

Moreover, we're not even formatting it on the QEMU command
line, ever: we just use it as part of some logic that decides
whether KVM support should be advertised, and as it turns out
that logic is actually buggy and dropping this capability
fixes it.

https://bugzilla.redhat.com/show_bug.cgi?id=1628469Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

After removing the host CPU model re-computation,
this function is no longer necessary.

This reverts commits:
commit d0498881
  virQEMUCapsFreeHostCPUModel: Don't always free host cpuData
commit 5276ec71
  testUpdateQEMUCaps: Don't leak host cpuData
Signed-off-by: NJán Tomko <jtomko@redhat.com>

We require QEMU 1.5.0 these days, so checking for versions
older than that is pointless.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The capability was introduced in QEMU 1.5.0, which is our
minimum supported QEMU version these days.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The capability was introduced in QEMU 1.3.1 and we require
QEMU 1.5.0 these days.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Commit 77f51ab5 started parsing an copying the SEV capabilities,
but omitted the free call.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Previous commits removed all capabilities from per-device property
probing for:

  pci-assign
  kvm-pci-assign
  usb-host
  scsi-generic

Remove them from the virQEMUCapsDeviceProps list and get rid of the
redundant device-list-properties QMP calls.

Note that 'pci-assign' was already useless, because the QMP version
of the device is called 'kvm-pci-assign', see libvirt commit 72574808
from 2012.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Introduced by QEMU commit 28b77657 in v1.0-rc4~21^2~8.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Introduced by QEMU commit c29029d which was included in 1.5.0
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Added by QEMU commit 65bb3a5 contained in v1.1.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Added by QEMU commit 65bb3a5 contained in v1.1.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

At the time of the addition of 'pci-assign' in QEMU commit
v1.3.0-rc0~572^2 the bootindex argument was already supported.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

At the time of the addition of 'pci-assign' in QEMU commit
v1.3.0-rc0~572^2 the configfd argument was already supported.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Added by commit fc66c160 and not used since.

Also, the device was present in QEMU 1.5.0 so this capability
will not be needed if we ever decide to implement usb-net support.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Historically the argv -> xml convertor wanted the same default machine
as we'd set when parsing xml. The latter has now changed, however, to
use a default defined by libvirt. The former needs fixing to again
honour the default QEMU machine.

This exposed a bug in handling for the aarch64 target, as QEMU does not
define any default machine. Thus we should not having been accepting
argv without a -machine provided.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The virQEMUCapsGetDefaultMachine() method doesn't get QEMU's default
machine any more, instead it gets the historical default that libvirt
prefers for each arch. Rename it, so that the old name can be used for
getting QEMU's default.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

We don't honour the QEMU default machine type anymore, always using the
libvirt chosen default instead. The QEMU argv parser, however, will need
to know the exacty QEMU default, so we must record that info.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>