For reference, these were generated by updating a local qemu git
repository to the latest upstream, making sure the latest dependencies
were met via "dnf builddep qemu" from my sufficiently privileged root
account, checking out the v2.10.0 tag, and building in order to generate
an "x86_64-softmmu/qemu-system-x86_64" image.

Then using a clean libvirt tree updated to master and built, the image
was then provided as input:

    tests/qemucapsprobe /path/to/x86_64-softmmu/qemu-system-x86_64 > \
       tests/qemucapabilitiesdata/caps_2.10.0.x86_64.replies

With the .replies file in place and the DO_TEST line added and build,
then running the following commands:

    touch tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml
    VIR_TEST_REGENERATE_OUTPUT=1 ./tests/qemucapabilitiestest

to generate tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml and both
were added to the commit.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Interestingly, none of the qemus we have caps for supported it ...
Reviewed-by: NEric Blake <eblake@redhat.com>

Drop all the monitor code necessary to do the downstream block jobs.
Reviewed-by: NEric Blake <eblake@redhat.com>

Block job QMP commands with underscores rather than dashes were never
released in upstream qemu, (they were added, but modified in the same
release [1]), but a certain distro managed to backport the version in the
middle.

The change also slightly modified semantics for the abort command, which
made us have a lot of code which was only ever present in certain
downstream distros.

Clean the upstream code from the legacy cruft and support only the
upstream implementations.

[1] See qemu commit v1.0-2176-gdb58f9c060
Reviewed-by: NEric Blake <eblake@redhat.com>

No need to pass a @driver parameter since all that's done is deref
the @cfg especially since the only caller can just pass an already
referenced @cfg.

Also, looks like commit id '0298531b' at one time had a different
name for the API, so I took the liberty of fixing the comments too
since I would already be updating them for the @cfg variable.

The documentation mistakenly states that the unit for returned
values is kB (multiple of 1000), while in fact we are returning
KiB (multiple of 1024).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

For a logged in user this a path like /dev/dri/renderD128 will have
default ownership root:video which won't work for the qemu:qemu user,
so we need to chown it.

We only do this when mount namespaces are enabled in the qemu driver,
so the chown'ing doesn't interfere with other users of the shared
render node path

https://bugzilla.redhat.com/show_bug.cgi?id=1460804

The VIR_SECURITY_MANAGER_MOUNT_NAMESPACE flag informs the DAC driver
if mount namespaces are in use for the VM. Will be used for future
changes.

Wire it up in the qemu driver

https://bugzilla.redhat.com/show_bug.cgi?id=1464313

If a Disk pool was defined/created using XML that either didn't
specify a specific format or specified format type='unknown', then
restarting a pool after an initial disk backend build with overwrite
would fail after a libvirtd restart for a non-autostarted pool.

This is because the persistent pool data is not updated during pool
build w/ overwrite processing to have the VIR_STORAGE_POOL_DISK_DOS
default format.

So in addition to the alteration done during disk build processing,
alter the default expectation for disk startup to be DOS if nothing
has been defined yet. That will either succeed if the pool had been
successfully built previously using the default DOS format or fail
with a message indicating the format is something else that does not
match the expect format 'dos'.

https://bugzilla.redhat.com/show_bug.cgi?id=1477880

If the "/#" is missing from the provided iSCSI path, then we need
to provide the default LUN of /0; otherwise, QEMU will fail to parse
the URL causing a failure to either create the guest or hotplug
attach the storage.

During post parse, for any iSCSI disk or hostdev, scan the source
path looking for the presence of '/', if found, then we can assume
the LUN is provided.  If not found, alter the input XML to add the
"/0".  This will cause the generated XML to have the generated
value when the domain config is saved after post parse.

Commit 703abf1d changed the logic so that we don't attempt to re-create
the image if it's a block device. This was done by modifying the
'reuse' variable. Unfortunately after modifying it one of the uses was
to infer whether we should probe the disk format. After changes in the
commit mentioned above we would attempt the probe if the target of the
copy is a block device and the format was not provided explicitly rather
than using the format of the disk.

Fix it by explicitly checking whether the user requested a reuse of the
disk rather than the modified boolean flag.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1490826

https://bugzilla.redhat.com/show_bug.cgi?id=1447169

Again, no special here.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1447169

With this patch users can cold plug a watchdog. Things are pretty
simple because a domain can have at most one watchdog device.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

If there was an error when constructing the buffer, NULL is
returned. The buffer is never freed though.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Some elements are offset just one space compared to their parent,
some are misaligned completely, and so on.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

If we have <choice/> with just one value to chose from, it's no
choice.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When destroying a domain libvirt marks it internally with a
beingDestroyed flag to make sure the qemuDomainDestroyFlags API itself
cleans up after the domain rather than letting an uninformed EOF handler
do it. However, when the domain is being started at the moment libvirt
was asked to destroy it, only the starting thread can properly clean up
after the domain and thus it ignores the beingDestroyed flag. Once
qemuDomainDestroyFlags finally gets a job, the domain may not be running
anymore, which should not be reported as an error if the domain has been
starting up.

https://bugzilla.redhat.com/show_bug.cgi?id=1445600Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

Requesting an automated switch to a post-copy migration (using
--timeout-postcopy) without actually enabling post-copy migration (using
--postcopy) doesn't really do anything. Let's make this dependency
explicit to avoid unexpected behavior.

https://bugzilla.redhat.com/show_bug.cgi?id=1455023Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This option requires:
  <ioapic driver='qemu'/>

Report an error in case someone tries to combine
it with different ioapic setting.

Setting 'eim' on without enabling 'intremap' does not make sense.

https://bugzilla.redhat.com/show_bug.cgi?id=1457610

Using intremap without <ioapic driver='qemu'/> does not work.
Merge the tests to avoid a duplicit test once we start validating it.

Simplify the formatting function even further.

Use the new helper to simplify the code.
This also fixes the bug of not formatting 'eim' in the useless
case if it's the only enabled attribute.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1368753Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

Since commit @ae2163f8, only active client connections or running
domains are allowed to inhibit daemon shutdown. The man page however
wasn't updated appropriately.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1325066Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

Add a 'cleanup' label and improve the readability of one of the
checks by making it conform to our formatting standard and moving
the corresponding comment.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

TPM 2 does not implement sysfs files for cancellation of commands.
We therefore use /dev/null for the cancel path passed to QEMU.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Tested-by: NJavier Martinez Canillas <javierm@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Add a new CPU model called 'EPYC' to model processors from AMD EPYC
family (which includes EPYC 76xx,75xx,74xx, 73xx and 72xx).

The following features bits have been added/removed compare to Opteron_G5

Added: monitor, movbe, rdrand, mmxext, ffxsr, rdtscp, cr8legacy, osvw,
       fsgsbase, bmi1, avx2, smep, bmi2, rdseed, adx, smap, clfshopt, sha
       xsaveopt, xsavec, xgetbv1, arat

Removed: xop, fma4, tbm

The patch is depend on EPYC CPU model supported introduced in qemu [1]

[1] https://patchwork.kernel.org/patch/9902205/

Cc: Tom Lendacky <Thomas.Lendacky@amd.com>
Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

In case of real migration (not migrating to file on save, dump etc)
migration info is not complete at time qemu finishes migration
in normal (non postcopy) mode. We need to update disks stats,
downtime info etc. Thus let's not expose this job status as
completed.

To archive this let's set status to 'qemu completed' after
qemu reports migration is finished. It is not visible as complete
job to clients. Cookie code on confirm phase will finally turn
job into completed. As we don't need more things to do when
migrating to file status is set to 'completed' as before
in this case.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When getting job info in case mirror does not reach ready phase
fetch mirror stats from qemu. Otherwise mirror stats are already
saved in current job.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Looks like it is more simple to drop this optimization as we are
going to add getting disks stats during migration via quering qemu
process and checking if we have to acquire job condition becomes
more complicate.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Instead of checking stat.status let's set status to migrating
as soon as migrate command is send (waiting for completion
is a good place too).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Setting status to none has little value - getting job status
will not return even elapsed time.

After this patch getting job stats stays correct in a sence
it will not fetch migration stats because it consults
stats.status before doing the fetch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Querying destination migration statistics may result in getting
a failure or getting a elapsed time value depending on stats.status
value which is odd. Instead let's always fail. Clients should
be ready to handle this as currently getting failure period
can be considerable.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemuMigrationFetchJobStatus is rather inconvinient. Some of its
callers don't need status to be updated, some don't need to update
elapsed time right away. So let's update status or elapsed time
in callers instead.

This patch drops updating job status on getting job stats by
client. This way we will not provide status 'completed' while
it is not yet updated by migration routine.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>