If the storage source has the query part set, format it in the output.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Add a new attribute for holding the query part for http(s) disks.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Since we are refreshing the relative paths when doing the blockjobs we
no longer need to load them upfront when doing the snapshot.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Preservation of the relative relationship requires us to load the
backing store strings from the disk images. With blockdev we stopped
detecting the backing chain if it's specified in the XML so the relative
links were not loaded at that point. To preserve the functionality from
the pre-blockdev without accessing the backing chain unnecessarily
during VM startup we must refresh the relative links when relative
block commit or block pull is requested.

https://bugzilla.redhat.com/show_bug.cgi?id=1818655Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

While it is impossible for VIR_ALLOC() to return an error, we
should be consistent with the rest of the code and not continue
initializing the virSecurityDeviceLabelDef structure.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Even with GLib it is still possible for virQEMUCapsNew() to
return NULL because it calls virQEMUCapsInitialize() which is a
wrapper over pthread_once() which may fail. At least, we still
check for its retval. If it so happens that the virQEMUCapsNew()
fails and returns NULL, we should not dereference it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Unfortunately, yajl_free() is not NOP on NULL. It really does
expect a valid pointer. Therefore, check whether the pointer we
want to pass to it is NULL or not.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The daemons are not supported on Win32 and therefore were not compiled
in that platform. However, with the daemon code sharing, all the code in
utils *is* compiled and it failed because `waitpid`, `fork`, and
`setsid` are not available. So, as before, let's not build them on
Win32 and make the code more portable by using existing vir* wrappers.
Signed-off-by: NRafael Fonseca <r4f4rfs@gmail.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NRafael Fonseca <r4f4rfs@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NRafael Fonseca <r4f4rfs@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NRafael Fonseca <r4f4rfs@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Several daemons have similar code around general daemon startup code.
Let's move it into a file and share it among them.
Signed-off-by: NRafael Fonseca <r4f4rfs@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The quotes are forbidden only inside the value, but the value itself may
be enclosed in quotes. Fix the RNG schema and validator and add a test
case.

https://bugzilla.redhat.com/show_bug.cgi?id=1804750Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Commit 5540acb9 added a minimum size verification for the target
size of ppc64 NVDIMMs but forgot to remove a MAX() size check that
was being used in earlier reviews of that commit. The size
verification makes this check unneeded since we're making sure
that guestArea will always be at least equal to ppc64AlignSize.

Fixes: 5540acb9Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

This is the only instance of g_autofree change applicable for
qemu_agent.c
Signed-off-by: NSeeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

This fixes a FreeBSD build error from

  commit a11a0e6e
  Author: Rafael Fonseca <r4f4rfs@gmail.com>
  Date:   Tue Mar 24 17:14:30 2020 +0100

    bhyve: move video default logic to driver
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Move the liveness check prior to the capability check. If the VM is
offline the capabilities are not initialized and thus we'd report the
wrong error.

https://bugzilla.redhat.com/show_bug.cgi?id=1812531Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

The code attempting to clean up after a failed pull mode backup job
wrongly entered monitor but didn't clean up nor exit monitor due to a
logic bug. Fix the condition.

Introduced in a1521f84

https://bugzilla.redhat.com/show_bug.cgi?id=1817327Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Move the liveness check prior to the capability check. If the VM is
offline the capabilities are not initialized and thus we'd report the
wrong error.

https://bugzilla.redhat.com/show_bug.cgi?id=1812531Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Host-model CPU definitions (and domain capabilities) will use the
original CPU models (without noTSX in their name) and explicitly disable
hle and rtm features. This way domains with host-model CPUs will be
migratable even to older versions of libvirt which do not support the
noTSX model variants.

The new models will be advertised in host capabilities and they may
be used explicitly with custom CPUs.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Tested-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Tested-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

The element specifies whether a particular CPU model can be used when
creating a CPU definition from raw CPUID/MSR data. The @host attribute
determines whether the CPU model can be used (host='on') for creating
CPU definition for host capabilities. Usability of the model for domain
capabilities and host-model CPU definitions is controlled by the @guest
attribute.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Tested-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

One of the mitigation methods for TAA[1] is to disable TSX
support on the host system.  Linux added a mechanism to disable
TSX globally through the kernel command line, and many Linux
distributions now default to tsx=off.  This makes existing CPU
models that have HLE and RTM enabled not usable anymore.

Add new versions of all CPU models that have the HLE and RTM
features enabled, that can be used when TSX is disabled in the
host system.

On systems disabling the features without those types defined
in cpu-maps users end up without modern CPU types in the list
of usable CPUs to use in the likes of virsh domcapabilities
or tools higher in the stack like virt-manager.

This adds:
-Cascadelake-Server-noTSX
-Icelake-Client-noTSX
-Icelake-Server-noTSX
-Skylake-Server-noTSX-IBRS
-Skylake-Client-noTSX-IBRS

Introduced in QEMU by commit v4.2.0-rc2-3-g9ab2237f19 (function)
                  and commit v4.2.0-rc2-4-g02fa60d101 (names)

References:

    [1] TAA, TSX asynchronous Abort:
        https://software.intel.com/security-software-guidance/insights/deep-dive-intel-transactional-synchronization-extensions-intel-tsx-asynchronous-abort
        https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.html

Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1853200Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Message-Id: <20200310104806.2723-2-christian.ehrhardt@canonical.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

The PMU feature is enabled by default in ppc64 guests and can't
be disabled via Libvirt or QEMU [1]. The current PMU feature
implementation does not allow PMU to enabled or disabled in the
ppc64 guest. Declaring the PMU feature will make the 'pmu'
property to be passed on to QEMU, but this property isn't
available for ppc64:

qemu-kvm: can't apply global host-powerpc64-cpu.pmu=on: Property '.pmu' not found

A similar error is thrown when trying to disable the PMU.

This patch standardizes the PMU handling for ppc64 guests by:

- throwing an error if the user attempts to set the feature to
'off', given that this feature can't be turned off at all;

- allowing the feature to be declared as 'on' in the domain XML.
This is done by skipping ppc64 guests when creating the command
line for this feature.

[1] https://www.redhat.com/archives/libvir-list/2020-March/msg00874.htmlSigned-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Hyperv features are supported by both x86 and aarch64. The <hyperv/>
declaration in the XML by itself is benign to other architectures,
but any of its 14 current features will break QEMU with an error
like this (from ppc64):

qemu-kvm: Expected key=value format, found hv_relaxed

This is a more extreme case than the one for apic eoi because we
would need an extra 'switch' statement, with all current Hyperv
features in the body of qemuDomainDefValidateFeatures(), to
check if the user attempted to activate any of them. It's easier to
simply fail to launch with any 'hyperv' declaration in the XML for
every arch which is not x86 and aarch64.

A fair disclaimer about Windows and PowerPC: the last Windows version
that ran in the architecture is the hall of famer Windows NT 4.0,
launched in 1996 and with end of extended support for the Server
version in 2004 [1]. I am acknowledging that there might be Windows
NT 4.0 users running in PowerPC, but not enough people running it
under KVM/QEMU to justify Libvirt allowing 'hyperv' to exist in the
domain XML of ppc64 domains.

[1] https://en.wikipedia.org/wiki/Windows_NT_4.0Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

The 'pvspinlock' feature is x86 only. The "<pvspinlock/>" declaration
will always have a value 'on' or 'off', and both will break QEMU when
launching non-x86 guests. This is the error message for
"<pvspinlock state='on'/>" when running a ppc64 guest:

qemu-kvm: Expected key=value format, found +kvm_pv_unhalt

A similar error message is thrown for "<pvspinlock state='off'/>".

This patch prevents non-x86 guests from launching with any
pvspinlock setting with a more informative error message:

error: unsupported configuration: The 'pvspinlock' feature is not
supported for architecture 'ppc64' or machine type 'pseries'
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

The "<apic/>" feature, although it's available only for x86 guests,
can be declared in the domain XML of other archs without errors.
But setting its 'eoi' attribute will break QEMU. For "<apic eoi='on'/>",
in a ppc64 guest:

qemu-kvm: Expected key=value format, found +kvm_pv_eoi

A similar error happens with eoi='off'.

One can argue that it's better to simply forbid launching non-x86
guests with "<apic/>" declared in the XML - it is a feature that
the architecture doesn't support and this would make it clearer
about it. This is sensible, but there are non-x86 guests that are
running with "<apic/>" declared in the domain (and A LOT of guests
running with "<acpi/>" for that matter, probably reminiscent of x86
templates that were reused for other archs) that will stop working if we
go this route.

A more subtle approach is to detect if the 'eoi' element is being set
for non-x86 guests and warn the user about it with a better error
message than the one QEMU provides. This is the new error message
when any value is set for the 'eoi' element in a ppc64 XML:

error: unsupported configuration: The 'eoi' attribute of the 'apic'
feature is not supported for architecture 'ppc64' or machine type
'pseries'.

https://bugzilla.redhat.com/show_bug.cgi?id=1236440Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Don't report cases when the guest information is not requested
explicitly and not present either.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Use qemuAgentCommandFull so that callers of qemuAgentGetFSInfo can
suppress error reports if the function is not supported by the guest
agent.

Since this patch removes the last use of
qemuAgentErrorCommandUnsupported the whole function is deleted as well.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Use qemuAgentCommandFull so that callers of qemuAgentGetTimezone can
suppress error reports if the function is not supported by the guest
agent.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Use qemuAgentCommandFull so that callers of qemuAgentGetOSInfo can
suppress error reports if the function is not supported by the guest
agent.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Use qemuAgentCommandFull so that callers of qemuAgentGetUsers can
suppress error reports if the function is not supported by the guest
agent.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Use qemuAgentCommandFull in qemuAgentGetHostname so that we can suppress
error reports if the caller will not require them. Callers for now
always require error reporting but will be fixed later.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Use g_autoptr instead.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Return 0 on success to match the documentation. The callers only check
for negative values.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

In some cases we don't want to log errors if an agent command is
unsupported. Wire it up into qemuAgentCheckError via qemuAgentCommandFull
and provide a thin wrapper (qemuAgentCommand) to prevent having to fix
all callers.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

'qemuDomainGetGuestInfoCheckSupport' despite its name was not checking
whether the info types are supported. Convert the function to return
integers and include the check.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The logic has been moved to the individual drivers.
Signed-off-by: NRafael Fonseca <r4f4rfs@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The logic setting a device default should be in the post parse function
of individual driver code.
Signed-off-by: NRafael Fonseca <r4f4rfs@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>