We do not have a pointer to the device here, just its source.

The domain definition is not needed in any of these functions.
Only pass it to qemuSetupChardevCgroup, which is used as a callback
for virDomainChrDefForeach.

Use the right type for passing virDomainObjPtr instead of
void* where possible.

Change CGroup to Cgroup to match other functions in the file.

like I440FX by moving the condition into qemuDomainMachineHasBuiltinIDE
and adding more machines.

Reference: http://bugs.debian.org/805189

Unlike other architectures, ppc64 domains need to lock memory
even when VFIO is not used.

Change qemuDomainRequiresMlock() to reflect this fact.

The amount of memory a ppc64 domain might need to lock is different
than that of a equally-sized x86 domain, so we need to check the
domain's architecture and act accordingly.

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

The function is used everywhere else to check whether the locked
memory limit should be set / updated, and it should be used here
as well.

Moreover, qemuDomainGetMlockLimitBytes() expects the hostdev to
have already been added to the domain definition, but we only do
that at the end of qemuDomainAttachHostPCIDevice(). Work around
the issue by adding the hostdev before adjusting the locked memory
limit and removing it immediately afterwards.

This removes a duplication of the logic used to decide whether
the memory locking limit should be set.

Commit id '08600de3' changed the prototype to reduce an argument, but
didn't adjust the ATTRIBUTE_NONNULL(11) to (10)

Remembering to call qemuMonitorSetDomainLog in the right paths before
calling qemuProcessStop is annoying and easy to forget. And I already
forgot to do so in commit v1.2.8-52-g03890605: logfd may be leaked if
QEMU process dies between Prepare and Finish migration phases.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Every caller setting migrateFrom already sets
VIR_QEMU_PROCESS_START_PAUSED flag anyway.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemuProcessMakeDir is used for creating a per-domain directory in a
given parent directory.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemuProcessStart is so big that any nontrivial code should be moved to
dedicated functions to make the code easier to read and maintain.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Move {Enter,Exit}Monitor calls inside qemuProcessSetLinkStates to
simplify qemuProcessStart.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemuProcessStart is so big that any nontrivial code should be moved to
dedicated functions to make the code easier to read and maintain.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemuProcessStart is so big that any nontrivial code should be moved to
dedicated functions to make the code easier to read and maintain.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemuProcessStart is so big that any nontrivial code should be moved to
dedicated functions to make the code easier to read and maintain.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

Traditionally, we pass incoming migration URI on QEMU command line,
which has some drawbacks. Depending on the URI QEMU may initialize its
migration state immediately without giving us a chance to set any
additional migration parameters (this applies mainly for fd: URIs). For
some URIs the monitor may be completely blocked from the beginning until
migration is finished, which means we may be stuck in qmp_capabilities
command without being able to send any QMP commands.

QEMU solved this by introducing "defer" parameter for -incoming command
line option. This will tell QEMU to prepare for an incoming migration
while the actual incoming URI is sent using migrate-incoming QMP
command. Before calling this command we can normally talk to the
monitor and even set any migration parameters which will be honored by
the incoming migration.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

We only started an async job for incoming migration from another host.
When we were starting a domain from scratch or restoring from a saved
state (migration from file) we didn't set any async job. Let's introduce
a new QEMU_ASYNC_JOB_START for these cases.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Incoming migration may require quite a few parameters (URI, fd, path) to
be considered while starting QEMU and we will soon add another one.
Let's group all of them in a single struct.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

Make callers of qemuBuildCommandLine responsible for providing the URI
which should be passed as a parameter for -incoming.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Move the code from qemuBuildCommandLine into dedicated functions.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Move the code from qemuMigrationFinish into a dedicated function.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

ppc64 guests don't require adding a NUMA node for hotplug memory to
work. Lift the requirement and add test cases.

Prepare the command line generator for the possibility that in some
configurations the target NUMA node info will be missing.

Adjust the config code so that it does not enforce that target memory
node is specified. To avoid breakage, adjust the qemu memory hotplug
config checker to disallow such config for now.

Aggregate the checks of the dimm device into the verification function
rather than having them in the formatter.

Add a function that will aggregate various checks related to memory
hotplug so that they aren't scattered accross various parts of the
code.

Since we already make sure before that the domain configuration is
valid we may execute it always at the cost of doing 0 iterations of the
for loop.

This patch will simplify later refactor as it will avoid whitespace
changes.

Make the function usable so that -1 can be passed to it as cell ID so
that we can later enable memory hotplug on non-NUMA guests for certain
architectures.

Based on Alex's explanation [1] in the recent discussion let's update
the comment explaining the memory lock limit calculation.

[1]
http://www.redhat.com/archives/libvir-list/2015-November/msg00329.html

Break early when hard limit is set so that it's not intermixed by other
logic for determining the limit.

Logging current async job while in BeginJob is useful, but the async job
we want to start is even more interesting.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

The previous commit

  commit 4e8993a2
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Mon Nov 9 16:20:08 2015 +0000

    qemu: assume various QEMU 0.10 features are always available

Added broken handling of -sdl. Instead of duplicating existing
SDL handling code, just ensure it is invoked in the right
scenarios.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The -sdl and -net ...name=XXX arguments were both introduced
in QEMU 0.10, so the QEMU driver can assume they are always
available.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

As of QEMU 0.10.0 the -vga argument was introduced, so the
QEMU driver can assume it is always available.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>