Trivial comment fix, reflecting the changes in
4ee2b318.
Signed-off-by: NLeonid Bloch <lb.workbox@gmail.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Previously, we used virCapabilitiesDomainDataLookup() to fill
machine type in post parse callback if none was provided in the
domain XML. If machine type couldn't be filled in an error was
reported. After 4a4132b4 we've changed it to
virQEMUCapsGetPreferredMachine() which returns NULL, but we no
longer report an error and proceed with the post parse callbacks
processing. This may lead to a crash because the code later on
assumes def->os.machine is not NULL.

Fixes: 4a4132b4Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>

When preparing to do a blockcopy, the mirror image is modified so
that QEMU can access it. For instance, the mirror has seclabels
set, if it is a NVMe disk it is detached from the host and so on.
And usually, the restore is done upon successful finish of the
blockcopy operation. But, if something fails then we need to
explicitly revoke the access to the mirror image (and thus
reattach NVMe disk back to the host).

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1822538Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Mores <pmores@redhat.com>

The idea behind this document is to show, with actual examples,
that users should not expect PCI addresses in the domain XML and
in the guest OS to match.

The first zPCI example already serves this purpose perfectly, so
in the interest of keeping the page as brief and easy to digest
as possible the second one is removed.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>

The section about VFIO devices is kept separate from the rest
because it's less about domain XML and guest OS disagreeing on the
PCI address of a device, and more about which of the two PCI
addresses in the domain XML is even relevant to the guest OS.

The section on zPCI addresses, on the other hand, falls squarely
in the "more complex cases" category, so it should live in the
corresponding section.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>

Indent all code snippets by the same number of spaces, and don't
embed the :: marker in the line preceding a code block.

This commit is best viewed with 'git show -w'.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>

When we do parallel migration, The multifd-channels migration parameter
needs to be set on the destination side as well before incoming migration
URI, unless we accept the default number of connections(2).

Usually, This can be correctly handled by libvirtd. But in this case if
we use p2p + xbzrle compression without parameter '--comp-xbzrle-cache',
qemuMigrationParamsDump returns too early, The corresponding migration
parameter will not be set on the destination side, It results QEMU hangs.

Reproducer:
virsh migrate --live --p2p --comp-methods xbzrle \
--parallel --parallel-connections 3 GUEST qemu+ssh://dsthost/system

or

virsh migrate --live --p2p --compressed \
--parallel --parallel-connections 3 GUEST qemu+ssh://dsthost/systemSigned-off-by: NLin Ma <lma@suse.com>
Message-Id: <20200416044451.21134-1-lma@suse.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Setting CC="ccache cc" works in most cases, but sometimes it will
break the build: in particular, we have experienced issues in the
past with that approach when using cgo to build our Go bindings.

A more robust approach is to have a directory containing symlinks
from the compiler name to the ccache binary: in that case, ccache
itself will invoke the compiler, and the build system will be none
the wiser.

Since libvirt-ci commit 2563aebb6c5c, container images contain a
suitable symlink directory, so all that's needed to enable the new
approach is to add this directory to $PATH.

Since we're touching this anyway, we make a few more changes:
$CCACHE_DIR is no longer created manually, because ccache will
take care of creating it for us if it doesn't already exist; the
ccache setup is moved out of the job template and into
script_variables, removing unnecessary duplication; a limit is
set on the size of the cache (500 MB, which is twice the amount
used by a fresh build on my Fedora 31 machine).
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Since libvirt-ci commit 27cfddee8835, paths to build tools such as
ninja and make are exported in the container's environment and can
be used directly.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Add some information on how pci address work on s390x.
Signed-off-by: NCornelia Huck <cohuck@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Fixes: 2923e7a3Reported-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

With libpmem support compiled into qemu it will trigger the following
denials on every startup.
  apparmor="DENIED" operation="open" name="/"
  apparmor="DENIED" operation="open" name="/sys/bus/nd/devices/"

This is due to [1] that tries to auto-detect if the platform supports
auto flush for all region.

Once we know all the paths that are potentially needed if this feature
is really used we can add them conditionally in virt-aa-helper and labelling
calls in case </pmem> is enabled.

But until then the change here silences the denial warnings seen above.

[1]: https://github.com/pmem/pmdk/blob/master/src/libpmem2/auto_flush_linux.c#L131

Bug: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1871354Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Acked-by: NJamie Strandboge <jamie@canonical.com>

This document describes the relationship between PCI addresses as
seen in the domain XML and by the guest OS, which is a topic that
people get confused by time and time again.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@redhat.com>

Add the appropriate entries into the schema to allow encryption of the
backup or scratch image. Since we use blockdev internals for everything
no changes to the code are actually necessary.

https://bugzilla.redhat.com/show_bug.cgi?id=1811906Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It was never implemented and for now I don't think there's demand to do
it. Remove the reference.

https://bugzilla.redhat.com/show_bug.cgi?id=1812100Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Starting with 3b076391
(v6.1.0-122-g3b076391) we support http cookies. Since they may contain
somewhat sensitive information we should not format them into the XML
unless VIR_DOMAIN_DEF_FORMAT_SECURE is asserted.
Reported-by: NHan Han <hhan@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

We want to format even the secure information in tests.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Commit 86608f78 added the above flag as an alias for ambiguous
'delete-snapshots' flag, but forgot to actually change the code that
extracts it, thus the new version actually doesn't work.

https://bugzilla.redhat.com/show_bug.cgi?id=1821988Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We always tried to install backing store for the image even if it didn't
make sense, e.g. for a full backup into a raw image. Additionally we
didn't record the backing file into the qcow2 metadata so the image
itself contained the diff of data but reading from it would be
incomplete as it depends on the backing image.

This patch fixes both issues by carefully installing the correct backing
file when appropriate and also recording it into the metadata when
creating the image.

https://bugzilla.redhat.com/show_bug.cgi?id=1813310Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We've adopted reStructuredText as the primary markup language for
our documentation and, given that both GitLab and GitHub can render
documents in this format just fine, it makes sense to get rid of
the few last remaining bits of Markdown and standardize on
reStructuredText across the board.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NSeeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

This is the last missing g_autofree conversion change in the module after
commit 1e2ae2e3 took care of the VIR_AUTOFREE conversion.
Signed-off-by: NSeeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Travis CI reports

  root: deprecated key sudo (The key `sudo` has no effect anymore.)

so let's drop it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

All information, except for osx_image image, is identical between
the two jobs so we can avoid repeating it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The newly-introduced CONTRIBUTING.rst serves the same purposes and
lives in the path where most people would look for it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It's generally expected that a git repository will contain this file,
which serves as an entry point for people interested in contributing
to the project.

In our case, we have extensive documentation available on the
website which we don't want to duplicate, so let's just point people
there.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

getaddrinfo returns linked list. Fix iteration accordingly.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

Before this patch we would simply rely on QEMU failing to attach the
device. Since we have a flag in the address set telling us which
controllers support hotplug, we can fail the operation sooner.

This also assures that when hotplugging with no provided PCI address,
that we skip any controllers with hotplug='off', and attempt to assign
the device to a controller that not only supports hotplug, but also
has it enabled.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The HOTPLUGGABLE flag is set for appropriates buses in a PCI address
set, and thnis patch updates virDomainPCIAddressFlagsCompatible() to
check the HOTPLUGGABLE flag when searching for a suitable bus/slot for
a device. No devices request HOTPLUGGABLE though (yet), so there is no
observable effect.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

virDomainPCIAddressBusSetModel() is called for each PCI controller
when building an address set prior to assiging PCI addresses to
devices.

This patch adds a new argument, allowHotplug, to that function that
can be set to false if we know for certain that a particular
controller won't support hotplug

The most interesting case is in qemuDomainPCIAddressSetCreate(), where
the config of each existing controller is available while building the
address set, so we can appropriately set allowHotplug = false when the
user has "hotplug='off'" in the config of a controller that normally
would support hotplug. In all other cases, it is set to true or false
in accordance with the capability of the controller model.

So far we aren't doing anything with this bus flag in the address set.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Old behavior: If the address was manually provided by config, copy
device AUTOASSIGN flag into the bus flag, and then later on in the
function *always* check for a match of the flags (which will always
match if the address came from config, since we just copied it).

New behavior: Don't mess with the bus flags - just directly check if
the AUTOASSIGN flag matches in bus and dev, but only make the check if
the address didn't come from config (i.e. it was auto-assigned by
libvirt).
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

When the HOTPLUGGABLE flag was originally added, it was set for all
the PCI controllers that accepted hotplugged devices, and requested
for all devices that were auto-assigned to a controller. While we're
still autoassigning to the same list of controllers, those controllers
may or may not support hotplug, so let's use the flag that fits what
we're actually doing.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

This new flag will be set for any controller that we decide can have
devices assigned to it automatically during PCI device assignment. In
the past PCI_CONNECT_TYPE_HOTPLUGGABLE was used for this purpose, but
that is overloading that flag, and no longer technically correct; what
we *really* want is to auto-assign devices to any pcie-root-port or
pcie-switch-downstream-port regardless of whether or not that
controller happens to have hotplug enabled.

This patch just adds the flag, but doesn't use it at all. Note that
the numbering of all the other flags was changed in order to insert
the new flag near the beginning of the list; that doesn't cause any
problem because the connect flags aren't stored anywhere between runs
of libvirtd.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

If a pcie-root-port or pcie-downstream-port has hotplug='off' in its
<target> subelement, and if the qemu binary supports the hotplug=false
option, then it will be added to the commandline for the pcie
controller. This controller will then not allow any hotplug/unplug of
devices while the guest is running (and the hotplug capability won't
be advertised to the guest OS, so the guest OS also won't present
unplugging of PCI devices as an option).

  <controller type='pci' model='pcie-root-port'>
    <target hotplug='off'/>
  </controller>

For any PCI controllers other than pcie-downstream-port and
pcie-root-port, of for qemu binaries that don't support the hotplug
commandline option, an error will be logged during validation.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

a <controller type='pci'...> element can now have a "hotplug"
attribute in the <target> subelement. This is intended to control
whether or not the slot(s) of the controller support
hotplugging/unplugging a device:

   <controller type='pci' model='pcie-root-port'>
     <target hotplug='off'/>
   </controller>

The default value of hotplug is "on".

Since support for configuring such an option is hypervisor-dependent
(and will vary among different types of PCI controllers even on a
single hypervisor), no validation is done in this patch - that
validation will be done in the patch that wires support for the
setting into the hypervisor.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

This caps flag is set when the qemu binary supports the option
"hotplug" for pcie-root-port, ioh3420 (Intel pcie-root-port) and
xio3130-downstream (Intel pcie-downstream-port). If it's available,
it's possible to disable hotplugging/unplugging devices on a
particular port by adding ",hotplug=off" to the qemu device
commandline. This option first appears in qemu-5.0.0.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

In a guest with only one vcpu, when pinning the emulator in say CPU184
and the vcpu0 in CPU0 of the host, the user might expect that only
CPU0 and CPU184 of the host will be used by the guest.

The reality is that Libvirt takes some time to honor the emulator
and vcpu pinning, taking care of NUMA constraints first. This will
result in other CPUs of the host being potentially used by the
QEMU thread until the emulator/vcpu pinning is done. The user
then might be confused by the output of 'virsh cpu-stats' in this
scenario, showing around 200 microseconds of cycles being spent
in other CPUs.

Let's document this behavior, which is explained in detail in
Libvirt commit v5.0.0-199-gf136b831, in the cputune section
of formatdomain.html.in.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Add support in the domXML<->native config converter for max_event_channels.
The parser and formater functions for max_grant_frames were reworked to
also parse max_event_channels. In doing so the xenbus controller is added
earlier in the config parsing, requiring a small adjustment to one of the
existing tests. Include a new test for the event channel conversion.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>