This patch introduces virNetServerGetProgramLocked. It's a function to
determine which program has to be used for a given @msg. This function
will be reused in the next patch.
Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

As a result, you can later determine during the callback which program
was used. This makes it easier to refactor the code in the future and
is less prone to error.
Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Use the return value of virObjectRef directly. This way, it's easier
for another reader to identify the reason why the additional reference
is required.
Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Following domain configuration changes create two memory bandwidth
monitors: one is monitoring the bandwidth consumed by vCPU 0,
another is for vCPU 5.

```
               <cputune>
                 <memorytune vcpus='0-4'>
                   <node id='0' bandwidth='20'/>
                   <node id='1' bandwidth='30'/>
       +           <monitor vcpus='0'/>
                 </memorytune>
       +         <memorytune vcpus='5'>
       +           <monitor vcpus='5'/>
       +         </memorytune>

               </cputune>
    ```
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NHuaqiang <huaqiang.wang@intel.com>

Originally, inside <cputune/cachetune>, it requires the <cache> element to
be in the position before <monitor>, and following configuration is not
permitted by schema, but it is better to let it be valid.

  <cputune>
    <cachetune vcpus='0-1'>
      <monitor level='3' vcpus='0-1'/>
            ^
            |__ Not permitted originally because it is in the place
                before <cache> element.

      <cache id='0' level='3' type='both' size='3' unit='MiB'/>
      <cache id='1' level='3' type='both' size='3' unit='MiB'/>
    </cachetune>
    ...
  </cputune>

And, let schema do more strict check by identifying following configuration to
be invalid, due to <cachetune> should contain at least one <cache> or <monitor>
element.

  <cputune>
    <cachetune vcpus='0-1'>
        ^
        |__ a <cachetune> SHOULD contain at least one <cache> or <monitor>

    </cachetune>
    ...
  </cputune>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NHuaqiang <huaqiang.wang@intel.com>

We learned that the hardware features of CAT, CMT, MBA and MBM
are orthogonal ones, if CAT or MBA is not supported in system,
but CMT or MBM are supported, then the cache monitor or
memoryBW monitor features may not be correctly displayed in
host capabilities through command 'virsh capabilites'.

Showing the cache/memoryBW monitor capabilities even there is
no support of cache allocation or memoryBW allocation features.
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NHuaqiang <huaqiang.wang@intel.com>

As of commit 2a00ef6e which
was released in v5.2.0, we require YAJL to build the QEMU driver.

Remove the checks from code that requires the QEMU driver
or checks that also check for WITH_QEMU.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Both the application developer guide and virsh command
reference are unmaintained for best part of 8 years, and
so horrifically out of date. This does not give a good
impression to people reading the docs. Now that we are
publishing the man pages online, those are a better
doc to read for virsh.  We can also highlight the API
reference instead of the app dev guide.

The virsh command reference & app dev guide will
still exist on the web root, but will not be linked
to.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Add Hygon Dhyana CPU data test case related files.
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NYingle Hou <houyingle@hygon.cn>

Add Hygon Dhyana CPU model to the processor model.
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NYingle Hou <houyingle@hygon.cn>

The x86ModelParseSignatures function makes an assumption that CPU signature
model equals 0 as an invalid case. While in Hygon processor definition, A1
version (model 0, stepping 1) is mass production version, to support Hygon
Dhyana A1 version, we have removed CPU signature model zero checking condition.
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NYingle Hou <houyingle@hygon.cn>

CVE-2019-11135

When TSX_CTRL bit of IA32_ARCH_CAPABILITIES MSR is set to 1, the CPU
supports IA32_TSX_CTRL MSR which can be used to disable and/or mask TSX.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

CVE-2019-11135

CPUs with TAA_NO bit of IA32_ARCH_CAPABILITIES MSR set to 1 are not
vulnerable to TSX Asynchronous Abort and passing this bit to a guest
may avoid unnecessary mitigations.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

To allow backups work across external snapshots we need to improve the
algorithm which calculates which bitmaps to merge.

The algorithm must look for appropriately named bitmaps in the image and
possibly descend into a backing image if the current image does not have
the bitmap.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

This function looks up a named bitmap for a virStorageSource in the data
returned from query-named-block-nodes.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Add test code which will crawl a fake internal list of checkpoints and
generate the list of bitmaps for merging to gather the final bitmap for
the backup.

The initial tests cover the basic case of all bitmaps being present in
the top layer of the backing chain.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

The function will require the bitmap topology for the full
implementation. To facilitate testing, add the propagation of the
necessary data beforehand so that the test code can stay unchanged
during the changes.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Separate the for now incomplete code that collects the bitmaps to be
merged for an incremental backup into a separate function. This will
allow adding testing prior to the improvement of the algorithm to
include snapshots.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

The object itself has no extra value and it would make testing the code
harder. Refactor it to remove just the definition pointer.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Add test data gathered from a run of qemu after creating bitmaps and
snapshots together in various combinations.

The following sequence of commands was used to achieve the
configuration:

virsh checkpoint-create-as VM --name a
virsh snapshot-create-as VM --disk-only
virsh snapshot-create-as VM --disk-only
virsh checkpoint-create-as VM --name b
virsh checkpoint-create-as VM --name c
virsh snapshot-create-as VM --disk-only
virsh checkpoint-create-as VM --name d
virsh snapshot-create-as VM --disk-only
virsh checkpoint-create-as VM --name current

Note that VM was restarted after these operations to allow renumbering
of the bitmaps in a more human-readable way.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Re-create any active persistent bitmap in the snapshot overlay image so
that tracking for a checkpoint is persisted. While this basically
duplicates data in the allocation map it's currently the only possible
way as qemu can't mirror the allocation map into a dirty bitmap if we'd
ever want to do a backup.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

qemuDomainSnapshotDiskPrepareOne is already called for each disk which
is member of the snapshot so we don't need to iterate through the
snapshot list again to generate members of the 'transaction' command for
each snapshot.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Check that the value is less than 0.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

The real data gathered for the 'basic' test case don't exercise some
fields. Add a copy with a few values modified manually.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Test the extraction of data about changed block tracking bitmaps. The
first test case adds a simple scenario of multiple bitmaps in one layer.

The test data will be also later reused for testing the code that
determines which bitmaps to merge for an incremental backup.

The sequence of bitmaps was created by the libvirt checkpoint API with
the following sequence of commands:

virsh checkpoint-create-as VM --name a
virsh checkpoint-create-as VM --name b
virsh checkpoint-create-as VM --name c
virsh checkpoint-create-as VM --name d
virsh checkpoint-create-as VM --name current
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

For testing purposes it will be beneficial to be able to parse the data
from JSON directly rather than trying to simulate the monitor. Extract
the worker bits and export them.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

We will need to inspect the presence and attributes for dirty bitmaps.
Extract them when processing reply of query-named-block-nodes.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Support for the mips architecture has been dropped from Debian
sid. Move the mipsel job from Debian 9 to Debian sid at the same
time to keep things balanced.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The use of the parseOpaque parameter was mistakenly removed in

  commit 4a4132b4
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   Tue Dec 3 10:49:49 2019 +0000

    conf: don't use passed in caps in post parse method

causing the method to re-fetch qemuCaps that were already just
fetched and put into parseOpaque.

This is inefficient when parsing incoming XML, but for live
XML this is more serious as it means we use the capabilities
for the current QEMU binary on disk, rather than the running
QEMU.

That commit, however, did have a useful side effect of fixing
a crasher bug in the qemu post parse callback introduced by

  commit 5e939cea
  Author: Jiri Denemark <jdenemar@redhat.com>
  Date:   Thu Sep 26 18:42:02 2019 +0200

    qemu: Store default CPU in domain XML

The qemuDomainDefSetDefaultCPU() method in that patch did not
allow for the possibility that qemuCaps would be NULL and thus
resulted in a SEGV.

This shows a risk in letting each check in the post parse
callback look for qemuCaps == NULL. The safer option is to
check once upfront and immediately stop (postpone) further
validation.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Don't check os type / virt type / arch in the post-parse callback
because we can't assume qemuCaps is non-NULL at this point. It
also conceptually belongs to the validation callback.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The status XML represents a running VM, so we should always have an
ID present for the domain.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

This function will be removed in a future commit because it allows the
caller to acquire both monitor and agent jobs at the same time. Holding
both job types creates a vulnerability to denial of service from a
malicious guest agent.

qemuDomainSetVcpusFlags() always passes NONE for either the monitor job
or the agent job (and thus is not vulnerable to the DoS), so we can
simply replace this function with the functions for acquiring the
appropriate type of job.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

We have to assume that the guest agent may be malicious so we don't want
to allow any agent queries to block any other libvirt API. By holding
a monitor job while we're querying the agent, we open ourselves up to a
DoS.

Split the function so that the portion issuing the agent command only
holds an agent job and the portion issuing the monitor command holds
only a monitor job.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

We have to assume that the guest agent may be malicious so we don't want
to allow any agent queries to block any other libvirt API. By holding a
monitor job while we're querying the agent, we open ourselves up to a
DoS.

So split the function up a bit to only hold the monitor job while
querying qemu for whether the domain supports suspend. Then acquire only
an agent job while issuing the agent suspend command.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

We have to assume that the guest agent may be malicious so we don't want
to allow any agent queries to block any other libvirt API. By holding
a monitor job while we're querying the agent, we open ourselves up to a
DoS.

Split the function so that we only hold the appropriate type of job
while rebooting.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

We have to assume that the guest agent may be malicious so we don't want
to allow any agent queries to block any other libvirt API. By holding
a monitor job while we're querying the agent, we open ourselves up to a
DoS.  So split the function into separate parts: one that does the agent
shutdown and one that does the monitor shutdown. Each part holds only a
job of the appropriate type.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>