Avoid a false positive since Coverity find a path in virResizeN which
could return 0 prior to the allocation of memory and thus flags a
possible NULL dereference. Instead allocate the output buffer based
on 'nparams' and only fill it partially if need be - shouldn't be too
much a waste of space. Quicker than multiple VIR_RESIZE_N calls or
two loops of STREQ's sandwiched around a single VIR_ALLOC_N using
'n' matches from a first loop to generate the 'n' addresses to return
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Commit id '81dd81e4' caused a regression when attempting to print a
specific vcpuid that is out of the range of the maximum vcpus for
the guest, such as:

 $ virsh vcpupin $dom 1000
 VCPU: CPU Affinity
 ----------------------------------

 $

Rather than just recover the old message, let's adjust the message based
on what would be displayed for a similar failure in the set path, such as:

 $ virsh vcpupin $dom 1000
 error: vcpu 1000 is out of range of persistent cpu count 2

 $ virsh vcpupin $dom 1000 --live
 error: vcpu 1000 is out of range of live cpu count 2

 $
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

QEMU working in vhost-user mode communicates with the other end (i.e.
some virtual router application) via unix domain sockets. This requires
that permissions for the socket files are correctly written into
/etc/apparmor.d/libvirt/libvirt-UUID.files.
Signed-off-by: NMichal Dubiel <md@semihalf.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inheritance among CPU model is cool but it makes reviewing CPU model
definitions and comparing them to CPU models from QEMU rather hard and
unpleasant. Let's define all CPU models from scratch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Sorted feature list is easier to review or compare.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

* docs/news.html.in libvirt.spec.in: updated for the release
* po/*po*: regenerated

Commit id 'cd490086' added a VIR_FORCE_CLOSE of the 'sock', but it
was after the VIR_FREE() of phyp_driver, resulting in a possible/likely
NULL dereference.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Convert virPCIDriverDir to return the buffer allocated (or not) and make the
appropriate check in the caller.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Convert virPCIDriverFile to return the buffer allocated (or not) and make the
appropriate check in the caller.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Convert virPCIFile to return the buffer allocated (or not) and make the
appropriate check in the caller.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

So, recently I was testing the LXC driver. You know, startup some
domains. But to my surprise, I was not able to start a single one:

  virsh # start --console test
  error: Reconnected to the hypervisor
  error: Failed to start domain test
  error: internal error: guest failed to start: unexpected exit status 125

So I've start digging. It turns out, that in virExec(), when I printed
out the @cmd, I got strange values: *(cmd->outfdptr) was certainly not
valid FD number: it has random value of several millions. This
obviously made prepareStdFd(childout, STDOUT_FILENO) fail (line 611).
But outfdptr is set in virCommandSetOutputFD(). The only place within
LXC driver where the function is called is in
virLXCProcessBuildControllerCmd(). If you take a closer look at the
function it looks like this:

static virCommandPtr
virLXCProcessBuildControllerCmd(virLXCDriverPtr driver,
                                ..
                                int logfd,
                                const char *pidfile)
{
    ...
    virCommandSetOutputFD(cmd, &logfd);
    virCommandSetErrorFD(cmd, &logfd);
    ...
}

Yes, you guessed it. @logfd is passed into the function by value.
However, in the function we try to get its address (an address of a
local variable) which is no longer valid once function is finished and
stack is cleaned. Therefore when cmd->outfdptr is evaluated at any
point after this function, we may get a random number, depending on
what's currently on the stack. Of course, this may work sometimes too
- it depends on the compiler how it arranges the code, when the stack
is wiped out.

In order to fix this, lets pass a pointer to @logfd instead of
figuring out (wrong) its value in a function.

The bug was introduced in e1de5521.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit id 'f967e7a6' didn't place the closing parentheses quite right
causing DEADCODE errors since the rc setting/comparison was wrong.

Using a custom device tree image may cause unexpected behavior in
architectures that use this approach to detect platform devices. Since
usually the device tree is generated by qemu and thus it's not normally
used let's taint VMs using it to make it obvious as a possible source of
problems.

The memory device hot(un)plug was missing calls to the auditing code.

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

Since the balloon driver does not guarantee that it returns memory to
the host, using the value in the audit message is not a good idea.

This patch removes auditing from updating the balloon size and reports
the total physical size at startup.

The code which generates paths for UNIX socket blindly used target name
without checking if it was set. Thus for the following device XML

    <channel type='unix'>
      <source mode='bind'/>
      <target type='virtio'/>
    </channel>

we would generate "/var/lib/libvirt/qemu/channel/target/NAME.(null)"
path which works but is not really correct. Let's not use the
".target_name" suffix at all if target name is not set.

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

While CPU0 was made unpluggable in Linux a while ago it's not desirable
to unplug it since some parts of the kernel (suspend-to-ram) still
depend on it.

This patch fixes the vCPU selection code in libvirt so that it will not
be disabled.

Signed-off-by: NLuyao Huang <lhuang@redhat.com>

The target type comparison in qemuDomainDetachChrDevice
used the VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE enum, so virtio-serial
addresses were not freed properly for channel devices.

Call qemuDomainReleaseDeviceAddress uncoditionally and decide
based on the address type instead of the target/device types.

Also check the device type when deciding what type the address should
be. Commit 9807c471 (aiming to fix another error in address allocation)
only checked the target type, but its value is different for different
device types. This resulted in an error when trying to attach
a channel with target type 'virtio':

error: Failed to attach device from channel-file.xml
error: internal error: virtio serial device has invalid address type

Make the logic for releasing the address dependent only on
* the address type
* whether it was allocated earlier
to avoid copying the device and target type checks.

https://bugzilla.redhat.com/show_bug.cgi?id=1230039Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>