Alter the node device deletion logic to make use of the parent field
from the obj->def rather than call virNodeDeviceObjListGetParentHost.
As it turns out the saved @def won't have parent_wwnn/wwpn or
parent_fabric_wwn, so the only logical path would be to call
virNodeDeviceObjListGetParentHostByParent which we can accomplish
directly via virNodeDeviceObjListFindByName.

There is no reason why two threads trying to look up two domains
should mutually exclude each other. Utilize new
virObjectRWLockable that was just introduced.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Up until now we only had virObjectLockable which uses mutexes for
mutually excluding each other in critical section. Well, this is
not enough. Future work will require RW locks so we might as well
have virObjectRWLockable which is introduced here.

Moreover, polymorphism is introduced to our code for the first
time. Yay! More specifically, virObjectLock will grab a write
lock, virObjectLockRead will grab a read lock then (what a
surprise right?). This has great advantage that an object can be
made derived from virObjectRWLockable in a single line and still
continue functioning properly (mutexes can be viewed as grabbing
write locks only). Then just those critical sections that can
grab a read lock need fixing. Therefore the resulting change is
going to be way smaller.

In order to avoid writer starvation, the object initializes RW
lock that prefers writers.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

We already have virRWLockInit. But this uses pthread defaults
which prefer reader to initialize the RW lock. This may lead to
writer starvation. Therefore we need to have the counterpart that
prefers writers. Now, according to the
pthread_rwlockattr_setkind_np() man page setting
PTHREAD_RWLOCK_PREFER_WRITER_NP attribute is no-op. Therefore we
need to use PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP
attribute. So much for good enum value names.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

virDomainXMLOptionNew() gladly accepts NULL and it is used in some
drivers.  There is no need for additional variable with no members set
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

It was observed while adding new property that there should be a space
before closing a curly brace in intel-iommu object property definition.
Fixing it as a separate patch.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>

When generating HTML documentation we put enum values into a
table so that we can display the value's name, numerical value
and description (if it has one). Now the last part is problem. If
the value doesn't have description the table row has just two
cells and if it has one the row counts three cells. This makes
HTML engines render the description into very little space - for
instance see:

  html/libvirt-libvirt-domain.html#virDomainMemoryStatTags

We can avoid this problem if we let the cell that corresponds to
numerical value span over two cells if there's no description.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

After f4cb85c6 we only have two options for placing enum
values descriptions. It's either:

    typedef enum {
        /* Some long description. Therefore it's placed before
         * the value. */
        VIR_ENUM_A_VAL = 1,
    } virEnumA;

or:

    typedef enum {
        VIR_ENUM_B_VAL = 1, /* Some short description */
    } virEnumB;

However, our apibuild.py script is not able to deal with the
former one. It messes up comments. To fix this couple of things
needs to be done:

a) DO NOT reset self.comment in parseEnumBlock(). This is a
result from our tokenizer. Upon calling token() if it finds a
comment block it stores it in self.comment and returns the next
token (which is not comment). Therefore, if we reset self.comment
we might lose the first comment in the enum block.

b) we need a variable to track if the current enum block uses
value descriptions before or after values. That is if it's type
virEnumA or virEnumB. Depending on that, it we're dealing with
virEnumA type and the current token is a comma ',' we can add the
value into the list as we already have everything needed:
comment, name and value.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

Currently, @port is type of string. Well, that's overkill and
waste of memory. Port is always an integer. Use it as such.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Split out parsing of one host into a separate function and add a new
function to loop through all the host XML nodes.

This change removes multiple levels of nesting due to the old XML
parsing approach used.

Similarly to when parsing XML we need to fill in default ports for the
backing chain. This was missed in commit 5bda8354

Since we now set the default ports when parsing disks, it's not
necessary to have default port numbers encoded in the command line
generator.

Negative ports don't make sense so use a unsigned integer.

Move it to virstring.c and improve it to parse and validate ports. New
name is virStringParsePort.

Commit id '905f1024' had a rogue editing mistake that inadvertently
dropped a goto cleanup in storagePoolSetAutostart, but Coverity noted it.

So the way we format this huge virQEMUCaps enum is we group the
values in groups of five. And then at the beginning of each group
we have a small comment that says what's the number of the first
item in the group. Well, the last commit of 11b2ebf3 does not
follow this formatting.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Alter the virStoragePoolObjNumOfVolumes, virStoragePoolObjVolumeGetNames,
and virStoragePoolObjVolumeListExport APIs to take a virStoragePoolObjPtr
instead of the &obj->volumes and obj->def.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

A virStoragePoolObjPtr will be an 'obj'.

A virStoragePoolPtr will be a 'pool'.

A virStorageVolPtr will be a 'vol'.

A virStorageVolDefPtr will be a 'voldef'.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

A virStoragePoolObjPtr will be an 'obj'.

Also modify the @matchpool to @matchobj.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Use the < 0 rather than == -1 (consistently) for virAsprintf errors.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Remove repetitive code, replace with common function.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than have repetitive code - create/use a couple of helpers:

    testStoragePoolObjFindActiveByName
    testStoragePoolObjFindInactiveByName

This will also allow for the reduction of some cleanup path logic.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rework some of the test driver API's to remove the need to return
failure when testStoragePoolObjFindByName returns NULL rather than
going to cleanup. This removes the need for check for "if (obj)" and in
some instances the need to for a cleanup label and a local ret variable.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

A virStoragePoolObjPtr will be an 'obj'.

A virStoragePoolPtr will be a 'pool'.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Fix some spacing/formatting in the storage pool/vol test driver code.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: Ndann frazier <dann.frazier@canonical.com>

Add a path for UEFI VMs for AArch32 VMs, based on the path Debian is using.
libvirt is the de facto canonical location for defining where distros
should place these firmware images, so let's define this path here to try
and minimize distro fragmentation.

The call to qemuBuildDeviceAddressStr() happens no matter
what, so we can move it to the outer possible scope inside
the function.

We can also move the call to virBufferAsprintf() after all
the checks have been performed, where it makes more sense.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

The virDomainDeviceInfo struct is defined in device_conf,
so generic functions that operate on it should also be
defined there rather than in domain_conf.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Follow the same style as other similar functions.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

All other virDomain*Def follow this naming convention for
their allocation function.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

This patch addresses the same aspects on PPC the bug 1103314 addressed
on x86.

PCI expander bus creates multiple primary PCI busses, where each of these
busses can be assigned a specific NUMA affinity, which, on x86 is
advertised through ACPI on a per-bus basis.

For SPAPR, a PHB's NUMA affinities are assigned on a per-PHB basis, and
there is no mechanism for advertising NUMA affinities to a guest on a
per-bus basis. So, even if qemu-ppc manages to get some sort of multi-bus
topology working using PXB, there is no way to expose the affinities
of these busses to the guest. It can only be exposed on a per-PHB/per-domain
basis.

So patch enables NUMA node tag in pci-root controller on PPC.

The way to set the NUMA node is through the numa_node option of
spapr-pci-host-bridge device. However for the implicit PHB, the only way
to set the numa_node is from the -global option. The -global option applies
to all the PHBs unless explicitly specified with the option on the
respective PHB of CLI. The default PHB has the emulated devices only, so
the patch prevents setting the NUMA node for the default PHB.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

The patch adds a capability for spapr-pci-host-bridge.numa_node.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Instead of going through two completely different code paths,
one of which repeats the same hardcoded bit of information
three times in rapid succession, depending on whether or not
a firmware list has been provided at configure time, just
provide a reasonable default value and remove the extra code.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

There are only two acceptable places for describing enum values.
It's either:

    typedef enum {
        /* Some long description. Therefore it's placed before
         * the value. */
        VIR_ENUM_A_VAL = 1,
    } virEnumA;

or:

    typedef enum {
        VIR_ENUM_B_VAL = 1, /* Some short description */
    } virEnumB;

However, during review of a patch sent upstream I realized that
is not always the case. I went through all the public header
files and identified all the offenders. Luckily there were just
two of them.

Yes, this makes our HTML generated documentation broken, but
that's bug of the generator. Our header files shouldn't be forced
to use something we don't want to.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

'numad' may return a nodeset which contains NUMA nodes without memory
for certain configurations. Since cgroups code will not be happy using
nodes without memory we need to store only numa nodes with memory in
autoNodeset.

On the other hand autoCpuset should contain cpus also for nodes which
do not have any memory.

Remove the code from qemuProcessPrepareDomain so that it won't get even
more bloated.

Decouple them by storing them in the XML separately rather than
regenerating them. This will simplify upcoming fixes.

Move the code to separate functions to avoid complicating the existing
ones with changes.