Both virProcessRunInMountNamespace() and virProcessRunInFork()
look very similar. De-duplicate the code and make
virProcessRunInMountNamespace() call virProcessRunInFork().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This new helper can be used to spawn a child process and run
passed callback from it. This will come handy esp. if the
callback is not thread safe.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Add a new memoryBacking source type "memfd", supported by QEMU (when
the capability is available).

A memfd is a specialized anonymous memory kind. As such, an anonymous
source type could be automatically using a memfd. However, there are
some complications when migrating from different memory backends in
qemu (mainly due to the internal object naming at this point, but
there could be more). For now, it is simpler and safer to simply
introduce a new source type "memfd". Eventually, the "anonymous" type
could learn to use memfd transparently in a separate change.

The main benefits are that it doesn't need to create filesystem files,
and it also enforces sealing, providing a bit more safety.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

QEMU 3.1 should only expose the property if the host is actually
capable of creating hugetable-backed memfd. However, it may fail
at runtime depending on requested "hugetlbsize".
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Check availability of "-object memory-backend-memfd".
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit ("qemu_domain.c: moving maxCpu validation to
qemuDomainDefValidate") shortened the code of qemuProcessStartValidateXML.
The function is called only by qemuProcessStartValidate, in the
same file, and its code is now a single check that calls virDomainDefValidate.

Instead of leaving a function call just to execute a single check,
this patch puts the check in the body of qemuProcessStartValidate in the
place where qemuProcessStartValidateXML was being called. The function can
now be removed.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Previous patch removed the call to qemuProcessValidateCpuCount
from qemuProcessStartValidateXML, in qemu_process.c. The only
caller left is qemuDomainDefValidate, in qemu_domain.c.

Instead of having a public function declared inside qemu_process.c
that isn't used in that file, this patch moves the function to
qemu_domain.c, making in static and renaming it to
qemuDomainValidateCpuCount to be compliant with other static
functions names in the file.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Adding maxCpu validation in qemuDomainDefValidate allows the user to
spot over the board maxCpus counts at editing time, instead of
facing a runtime error when starting the domain. This check is also
arch independent.

This leaves us with 2 calls to qemuProcessValidateCpuCount: one in
qemuProcessStartValidateXML and the new one at qemuDomainDefValidate.

The call in qemuProcessStartValidateXML is redundant. Following
up in that code, there is a call to virDomainDefValidate, which
in turn will call config.domainValidateCallback. In this case, the
callback function is qemuDomainDefValidate. This means that, on startup
time, qemuProcessValidateCpuCount will be called twice.

To avoid that, let's also remove the qemuProcessValidateCpuCount call
from qemuProcessStartValidateXML.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

qemuValidateCpuCount validates the maxCpus value of a domain at
startup time, preventing it to start if the value exceeds a maximum.

This checking is also done at qemu_domain.c, qemuDomainDefValidate.
However, it is done only for x86 (and even then, in a specific
scenario). We want this check to be done for all archs.

To accomplish this, let's first make qemuValidateCpuCount public so
it can be used inside qemuDomainDefValidate. The function was renamed
to qemuProcessValidateCpuCount to be compliant with the other public
methods at qemu_process.h. The method signature was slightly adapted
to fit the const 'def' variable used in qemuDomainDefValidate. This
change has no downside in in its original usage at
qemuProcessStartValidateXML.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Adding the maxCpus value in the error message of qemuValidateCpuCount
allows the user to set an acceptable maxCpus count without knowing
QEMU internals.

x86 guests, that might have been created prior to the x86
qemuDomainDefValidate maxCpus check code (that validates the maxCpus value
in editing time), will also benefit from this change.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The commit 89563efc fix the
monitor error when closing the QEMU monitor. The QEMU agent
has a problem similar to QEMU monitor. So fix the QEMU agent
with the same method.
Signed-off-by: NWang Yechao <wang.yechao255@zte.com.cn>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

We were mistakenly skipping virZPCIDeviceAddressIsEmpty() and
virZPCIDeviceAddressIsValid() when compiling on non-Linux,
which unsurprisingly ended up causing linking failures later
in the build process.
Clue-stick-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Signed-off-by: NYi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

This commit adds hotplug support for PCI devices on S390 guests.
There's no need to implement hot unplug for zPCI as QEMU implements
an unplug callback which will unplug both PCI and zPCI device in a
cascaded way.
Currently, the following PCI devices are supported:
  virtio-blk-pci
  virtio-net-pci
  virtio-rng-pci
  virtio-input-host-pci
  virtio-keyboard-pci
  virtio-mouse-pci
  virtio-tablet-pci
  vfio-pci
  SCSIVhost device
Signed-off-by: NYi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Add new functions to generate zPCI command string and append it to
QEMU command line. And the related tests are added.
Signed-off-by: NYi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Update 'Device address' section to describe 'zpci' element and
its two attributes 'uid' and 'fid'.
Signed-off-by: NYi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

This patch adds new functions for reservation, assignment and release
to handle the uid/fid. If the uid/fid is defined in the domain XML,
they will be reserved directly in the collecting phase. If any of them
is not defined, we will find out an available value for them from the
zPCI address hashtable, and reserve them. For the hotplug case there
might not be a zPCI definition. So allocate and reserve uid/fid the
case. Assign if needed and reserve uid/fid for the defined case.
Signed-off-by: NYi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

We should ensure that QEMU supports zPCI when a zPCI address is defined
in XML and otherwise report an error. This patch introduces a generic
validation function qemuDomainDeviceDefValidateAddress() which calls
qemuDomainDeviceDefValidateZPCIAddress() if address type is PCI address.
Signed-off-by: NYi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

This patch introduces new XML parser/formatter functions. Uid is
16-bit and non-zero. Fid is 32-bit. They are the two attributes of zpci
which is introduced as PCI address element. Zpci element is parsed and
formatted along with PCI address. And add the related test cases.
Signed-off-by: NYi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

In order to add zPCI child element for PCI address, we update
virDomainDeviceInfoFormat() to format device info by helper function
virXMLFormatElement(). Then we could simply format zPCI address into
child buffer later.
Signed-off-by: NYi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

The pci-root depends on zpci capability. So autogenerate pci-root if
zpci exists.
Signed-off-by: NYi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

This patch provides a caching mechanism for the device address
extensions uid and fid on S390. For efficient sparse address allocation,
we introduce two hash tables for uid/fid which hold the address set
information per domain. Also in order to improve performance of
searching available value, we introduce our own callbacks for the two
hashtables. In this way, uid/fid is saved in hash key and hash value
could be any non-NULL pointer due to no operation on hash value. That is
also the reason why we don't introduce hash value free callback.
Signed-off-by: NYi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

This patch introduces PCI address extension flag for virDomainDeviceInfo
and virPCIDeviceAddress. The extension flag in virDomainDeviceInfo is
used internally during calculating PCI extension flag. The one in
virPCIDeviceAddress is the duplicate to indicate extension address is
being used. Currently only zPCI extension address is introduced to deal
with 'uid' and 'fid' on the S390 platform.
Signed-off-by: NYi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

QEMU on s390 supports PCI multibus since forever.
Signed-off-by: NYi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Let's introduce zPCI capability.
Signed-off-by: NYi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Add zPCI definitions in preparation of extending the PCI address
with parameters uid (user-defined identifier) and fid (PCI function
identifier).
Signed-off-by: NYi Min Zhao <zyimin@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

The QEMU driver now has support for Hyper-V PV IPI and Enlightened VMCS
for Windows and Hyper-V guests.
Suggested-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>

QEMU 3.1 supports Hyper-V Enlightened VMCS feature which significantly
speeds up nested Hyper-V on KVM environments.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>

Support Hyper-V Enlightened VMCS in domain config. QEMU support will
be implemented in the next patch, adding interim VIR_DOMAIN_HYPERV_EVMCS
cases to src/qemu/* for now.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>

QEMU 3.1 supports Hyper-V-style PV IPIs making it cheaper for Windows
guests to send an IPI, especially when it targets many CPUs.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>

Support Hyper-V PV IPI enlightenment in domain config. QEMU support will
be implemented in the next patch, adding interim VIR_DOMAIN_HYPERV_IPI
cases to src/qemu/* for now.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>

Remove redundant leading whitespaces from "<td> on, off</td>".
Suggested-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>

This is a simple removal of a duplicated check of the return of the
filter function. There is a nested conditional checking exactly the same
thing since commit c9ede1cf removed the (ret > 0) check condition.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The function qemuDomainGetHostdevPath() is using VIR_FREE to free the
paths stored in tmpPaths. Both syntax analyzer are reporting a warning
about this. Replacing the old method to function
virStringListFreeCount() fixes the warnings/errors.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This commit includes new test cases to cover LXC version 3.0 and higher.
This LXC version rebased some settings entries and deprecated other ones.
As we support both, we should include tests to minimize problems with
integration between them.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This patch introduce the new settings for LXC 3.0 or higher. The older
versions keep the compatibility to deprecated settings for LXC, but
after release 3.0, the compatibility was removed. This commit adds the
support to the refactored settings.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Add a test to fetch the GetMemoryStat output. This only gets
data for v1 only right now since the v2 data from commit 61ff6021
is rather useless returning all 0's. The v1 data was originally
added in commit d1452470.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Commit 901d2b9c introduced virCgroupGetMemoryStat and replaced
the LXC virLXCCgroupGetMemStat logic in commit e634c7cd. However,
in doing so the replacement wasn't exact as the LXC logic used
getline() to process the cgroup controller data, while the new
virCgroupGetMemoryStat used "memory.stat" manual buffer read/
processing which neglected to forward through @line in order
to read each line in the output.

To fix that, we should be sure to carry forward the @line value
for each line read updating it beyond that current @newLine value
once we've calculated the values that we want.
Signed-off-by: NPeter Chubb <peter.chubb@data61.csiro.au>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

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

If polkit authentication is enabled, an attempt to open
the connection failed during virAccessDriverPolkitGetCaller
when the call to virIdentityGetCurrent returned NULL resulting
in the errors:

  virAccessDriverPolkitGetCaller:87 : access denied:
  Policy kit denied action org.libvirt.api.connect.getattr from <anonymous>

Because qemuProcessReconnect runs in a thread during
daemonRunStateInit processing it doesn't have the thread
local identity. Thus when the virGetConnectNWFilter is
called as part of the qemuProcessFiltersInstantiate when
virDomainConfNWFilterInstantiate is run the attempt to get
the idenity fails and results in the anonymous error above.

To fix this, let's grab/use the virIdenityPtr of the process
that will be creating the thread, e.g. what daemonRunStateInit
has set and use that for our thread. That way any other similar
processing that uses/requires an identity for any other call
that would have previously been successfully run won't fail in
a similar manner.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

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

Changes made to manage and utilize a secondary connection
driver to APIs outside the scope of the primary connection
driver have resulted in some confusion processing polkit rules
since the simple "access denied" error message doesn't provide
enough of a clue when combined with the "authentication failed:
access denied by policy" as to which connection driver refused
or failed the ACL check.

In order to provide some context, let's modify the existing
"access denied" error returned from the various vir*EnsureACL
API's to provide the connection driver name that is causing
the failure. This should provide the context for writing the
polkit rules that would allow access via the driver, but yet
still adhere to the virAccessManagerSanitizeError commentary
regarding not telling the user why access was denied.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>