There is one limitation for using this API, when the guest is started
with all actions set to "destroy" we put "-no-reboot" on the QEMU
command line.  That cannot be changed while QEMU is running and
the QEMU process is always terminated no matter what is configured
for any action.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1460677Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

We need to send allowReboot in the migration cookie to ensure the same
behavior of the virDomainSetLifecycleAction() API on the destination.

Consider this scenario:

    1. On the source the domain is started with:
        <on_poweroff>destroy</on_poweroff>
        <on_reboot>restart</on_reboot>
        <on_crash>destroy</on_crash>

    2. User calls an API to set "destroy" for <on_reboot>:
        <on_poweroff>destroy</on_poweroff>
        <on_reboot>destroy</on_reboot>
        <on_crash>destroy</on_crash>

    3. The guest is migrated to a different host

    4a. Without the allowReboot in the migration cookie the QEMU
        process on destination would be started with -no-reboot
        which would prevent using the virDomainSetLifecycleAction() API
        for the rest of the guest lifetime.

    4b. With the allowReboot in the migration cookie the QEMU process
        on destination is started without -no-reboot like it was started
        on the source host and the virDomainSetLifecycleAction() API
        continues to work.

The following patch adds a QEMU implementation of the
virDomainSetLifecycleAction() API and that implementation disallows
using the API if all actions are set to "destroy" because we add
"-no-reboot" on the QEMU command line.  Changing the lifecycle action
is in this case pointless because the QEMU process is always terminated.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This will be used later on in implementation of new API
virDomainSetLifecycleAction().  In order to use it, we need to store
the value in status XML to not lose the information if libvirtd is
restarted.

If some guest was started by old libvirt where it was not possible
to change the lifecycle action for running guest, we can safely
detect it based on the current actions from the status XML.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Extract the required data inside a function instead of passing it
all as arguments.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

There is no need to have two different enums where one has the same
values as the other one with some additions.

Currently for on_poweroff and on_reboot we allow only subset of actions
that are allowed for on_crash.  This was covered in parse time using
two different enums.  Now to make sure that we don't allow setting
actions that are not supported we need to check it while validating
domain config.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Commit v3.8.0-95-gfd885a06 dropped nmodels parameter from several APIs
in src/cpu/cpu.h, but failed to update all callers.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

If we find ourselves in the situation that the 'add' uevent has been
fired earlier than the sysfs tree for a device was created, we should
use the best-effort approach and give kernel some predetermined amount
of time, thus waiting for the attributes to be ready rather than
discarding the device from our device list forever. If those don't appear
in the given time frame, we need to move on, since libvirt can't wait
indefinitely.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1463285Signed-off-by: NErik Skultety <eskultet@redhat.com>

Since we have a number of places where we workaround timing issues with
devices, attributes (files in general) not being available at the time
of processing them by calling usleep in a loop for a fixed number of
tries, we could as well have a utility function that would do that.
Therefore we won't have to duplicate this ugly workaround even more.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Adjust udevEventHandleThread to be a proper thread routine running in an
infinite loop handling devices. The handler thread pulls all available
data from the udev monitor and only then waits until a wakeup signal for
new incoming data has been emitted by udevEventHandleCallback.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

This patch splits udevEventHandleCallback in two (introduces
udevEventHandleThread) in order to be later able to refactor the latter
to actually become a normal thread which will wait some time for the
kernel to create the whole sysfs tree for a device as we cannot do that
in the event loop directly.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

udevSetupSystemDev only needs the udev data lock to be locked because of
calling udevGetDMIData which accesses some protected structure members,
but it can do that on its own just fine, no need to hold the lock the
whole time.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

The driver locks are unnecessary here, since currently the cleanup is
only called from the main daemon thread, so we can't race here. Moreover
@devs and @privateData are self-lockable objects, so no problem there
either.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Since there's going to be a worker thread which needs to have some data
protected by a lock, the whole code would just simply get unnecessary
complex, since two sets of locks would be necessary, driver lock (for
udev monitor and event handle) and a mutex protecting thread-local data.
Given the future thread will need to access the udev monitor socket as
well, why not protect everything with a single lock, even better, by
converting the driver's private data to a lockable object, we get the
automatic object disposal feature for free.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

We need to perform a sanity check on the udev monitor before every
use so that we know nothing has changed in the meantime. The reason for
moving the code to a separate helper is to enhance readability and shift
the focus on the important stuff within the udevEventHandleCallback
handler.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Even though hal doesn't make use of it, the privileged flag is related
to the daemon/driver rather than the backend actually used.
While at it, get rid of some tab indentation in the driver state struct.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Option --full will always display the name and MAC address of the
the interface. Both virsh help and virsh man page didn't mention that.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

There were a bunch of commentary blocks that were literally useless in
terms of describing what the code following them does, since most of
them were documenting "the obvious" or it just wouldn't help at all.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

So we have a syntax-check rule to catch all tab indents but it naturally
can't catch tab spacing, i.e. as a delimiter. This patch is a result of
running 'vim -en +retab +wq'
(using tabstop=8 softtabstop=4 shiftwidth=4 expandtab) on each file from
a list generated by the following:
find . -regextype gnu-awk \
         -regex ".*\.(rng|syms|html|s?[ch]|py|pl|php(\.code)?)(\.in)?" \
         | xargs git grep -lP "\t"
Signed-off-by: NErik Skultety <eskultet@redhat.com>

When formatting an inactive or migratable XML we will need to suppress
backing chain members which were detected from the disk to keep
semantics straight. This means we need to record, whether a
virStorageSource originates from autodetection.

qemuBlockStorageSourceGetBackendProps now is able to format the JSON
definition for regular storage too.

The file object is needed when formatting the command line, but it makes
nesting of the objects less easy for use with blockdev. Separate the
wrapping into the 'file' object into a helper used specifically for disk
sources in the old code path.

Move qemuFreeKeywords into qemu_parse_command.c as
qemuParseKeywordsFree and call it rather than inline code
in multiple places.
Signed-off-by: NKothapally Madhu Pavan <kmp@linux.vnet.ibm.com>

The original description from commit id '24e0171b' got it backwards.

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Without the fix in the previous patch the JSON data from QEMU would be
interpreted as Haswell-noTSX because x86DataFilterTSX would filter rtm
and hle features as a result of

    family == 6 && model == 63 && stepping < 4

test even though this CPU has stepping == 4.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Even though only family and model are used for matching CPUID data with
CPU models from cpu_map.xml, stepping is used by x86DataFilterTSX which
is supposed to disable TSX on CPU models with broken TSX support. Thus
we need to start parsing stepping from QEMU to make sure we don't
disable TSX on CPUs which provide working TSX implementation. See the
following patch for a real world example of such CPU.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

If same boot order is specified twice (or more) in domain xml
we call free for uninitiaziled loadparm on cleanup in virDomainDeviceBootParseXML
and SIGABRT (or similar) as a result.

When libvirt older than 3.9.0 reconnected to a running domain started by
old libvirt it could have messed up the expansion of host-model by
adding features QEMU does not support (such as cmt). Thus whenever we
reconnect to a running domain, revert to an active snapshot, or restore
a saved domain we need to check the guest CPU model and remove the
CPU features unknown to QEMU. We can do this because we know the domain
was successfully started, which means the CPU did not contain the
features when libvirt started the domain.

https://bugzilla.redhat.com/show_bug.cgi?id=1495171Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

When reconnecting to a domain started with a host-model CPU which was
started by old libvirt that did not replace host-model with the real CPU
definition, libvirt replaces the host-model CPU with the CPU from
capabilities (because this is what the old libvirt did when it started
the domain). Without this patch libvirt could use features unknown to
QEMU in the CPU definition which replaced the original host-model CPU.
Such domain would keep running just fine, but any attempt to migrate it
will fail and once the domain is saved or snapshotted, restoring it
would fail too.

In other words whenever we want to use the CPU definition from host
capabilities as a guest CPU definition, we have to filter the unknown
features.

https://bugzilla.redhat.com/show_bug.cgi?id=1495171Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>