With this commit we finally have a way to read and manipulate basic resctrl
settings.  Locking is done only on exposed functions that read/write from/to
resctrlfs.  Not in functions that are exposed in virresctrlpriv.h as those are
only supposed to be used from tests.

More information about how resctrl works:

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/x86/intel_rdt_ui.txtSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This will make the current functions obsolete and it will provide more
information to the virresctrl module so that it can be used later.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

For two string lists merge one into the other one.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This new API reads host's CPU microcode version from /proc/cpuinfo.

Unfortunately, there is no other way of reading microcode version which
would be usable from both system and session daemon.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Add a function to filter a string based on a list of valid characters.

These are already exported at header file level because of
VIR_ENUM_DECL being in numa_conf.h. However, they are not being
exported at object level because of missing libvirt_private.syms
record.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This will be the first private piece of data that will need to be stored
in the XML for some drivers. Add helpers which will do it.

Now that we have a private storage pool list, we can take the next
step and convert to using objects. In this case, we're going to use
RWLockable objects (just like every other driver) with two hash
tables for lookup by UUID or Name.

Along the way the ForEach and Search API's will be adjusted to use
the related Hash API's and the various FindBy functions altered and
augmented to allow for HashLookup w/ and w/o the pool lock already
taken.

After virStoragePoolObjRemove we will need to virObjectUnref(obj)
after to indicate the caller is "done" with it's reference. The
Unlock occurs during the Remove.

The NumOf, GetNames, and Export functions all have their own callback
functions to return the required data and the FindDuplicate code
can use the HashSearch function callbacks.

Move the structure into virstorageobj.c.

Use the virStoragePoolObjListNew allocator to fill in the @pools for
the storage driver and test driver.

SELinux and DAC drivers already have both functions but they were not
exported as public API of security manager.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Allow parts of code outside domain_conf to decide whether the alias
is user-specified or not.

Target model and target type must agree for the configuration
to make sense, so check that's actually the case and error out
otherwise.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Export the existing DAC and SELinux for separate use and introduce
functions for stack, nop and the security manager.

Use it to denadify qemuDomainSetupInput.

Now that we're moved the object into virstorageobj, let's make the
code use the lockable object.

Create an API to search through the storage pool objects looking for
a specific truism from a callback API in order to return the specific
storage pool object that is desired.

Create an API to walk the pools->objs[] list in order to perform a
callback function for each element of the objs array that doesn't care
about whether the action succeeds or fails as the desire is to run the
code over every element in the array rather than fail as soon as or if
one fails.

For now it'll just call the virStoragePoolObjUnlock, but a future
adjustment will do something different. Since the new API will check
for a NULL object before the Unlock call, callers no longer need to
check for NULL before calling.

The virStoragePoolObjUnlock is now private/static to virstorageobj.c
with a short term forward reference.

The function returns true/false depending on distance
configuration being present in the domain XML.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Sometimes the size of the bitmap matters and it might not be guessed correctly
when parsing from some type of input.  For example virBitmapNewData() has Byte
granularity, virBitmapNewString() has nibble granularity and so on.
virBitmapParseUnlimited() can be tricked into creating huge bitmap that's not
needed (e.g.: "0-2,^99999999").  This function provides a way to shrink the
bitmap.  It is not supposed to free any memory.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Already introduced in the past with 9479642f, but then renamed to
virBitmapIntersect by a908e9e4.  This time we'll really use it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Our bitmaps can be represented as data (raw bytes for which we have
virBitmapNewData() and virBitmapToData()), human representation (list
of numbers in a string for which we have virBitmapParse() and
virBitmapFormat()) and hexadecimal string (for which we have only
virBitmapToString()).  So let's add the missing complement for the
last one so that we can parse hexadecimal strings.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

It is literally only a wrapper around virBitmapNewData() and
virBitmapFormat(), only the naming was wrong since it was introduced.
And because we have virBitmap*String functions where the meaning of
the 'String' is constant, this might confuse someone.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This follows the virBitmapToData() function and, similarly to
virBitmapNewData(), we'll be able to have virBitmapNewString() later
on without name confusion.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

We can't output better memory sizes if we want to be compatible with libvirt
older than the one which introduced /memory/unit, but for new things we can just
output nicer capacity to the user if available.  And this function enables that.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Most of the time it's okay to leave this up to negotiation between
the guest and the host, but in some situations it can be useful to
manually decide the behavior, especially to enforce its availability.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1308743Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This patch converts NUMA configurations between the Xen libxl
configuration file format and libvirt's XML format.

XML HVM domain on a 4 node (2 cores/socket) configuration:

  <cpu>
    <numa>
      <cell id='0' cpus='0-1' memory='2097152' unit='KiB'>
        <distances>
          <sibling id='0' value='10'/>
          <sibling id='1' value='21'/>
          <sibling id='2' value='31'/>
          <sibling id='3' value='21'/>
        </distances>
      </cell>
      <cell id='1' cpus='2-3' memory='2097152' unit='KiB'>
        <distances>
          <sibling id='0' value='21'/>
          <sibling id='1' value='10'/>
          <sibling id='2' value='21'/>
          <sibling id='3' value='31'/>
        </distances>
      </cell>
      <cell id='2' cpus='3-4' memory='2097152' unit='KiB'>
        <distances>
          <sibling id='0' value='31'/>
          <sibling id='1' value='21'/>
          <sibling id='2' value='10'/>
          <sibling id='3' value='21'/>
        </distances>
      </cell>
      <cell id='3' cpus='5-6' memory='2097152' unit='KiB'>
        <distances>
          <sibling id='0' value='21'/>
          <sibling id='1' value='31'/>
          <sibling id='2' value='21'/>
          <sibling id='3' value='10'/>
        </distances>
      </cell>
    </numa>
  </cpu>

Xen xl.cfg domain configuration:

  vnuma = [["pnode=0","size=2048","vcpus=0-1","vdistances=10,21,31,21"],
           ["pnode=1","size=2048","vcpus=2-3","vdistances=21,10,21,31"],
           ["pnode=2","size=2048","vcpus=4-5","vdistances=31,21,10,21"],
           ["pnode=3","size=2048","vcpus=6-7","vdistances=21,31,21,10"]]

If there is no XML <distances> description amongst the <cell> data the
conversion schema from xml to native will generate 10 for local and 20
for all remote instances.
Signed-off-by: NWim ten Have <wim.ten.have@oracle.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This function works over domain definition and not domain object.
Its name is thus misleading.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

When coverage build is enabled, gcc complains about it:

In file included from qemu/qemu_agent.h:29:0,
                 from qemu/qemu_driver.c:47:
qemu/qemu_driver.c: In function 'qemuDomainSetInterfaceParameters':
./conf/domain_conf.h:3397:1: error: inlining failed in call to
'virDomainNetTypeSharesHostView': call is unlikely and code size would
grow [-Werror=inline]
 virDomainNetTypeSharesHostView(const virDomainNetDef *net)
 ^
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The optional values are 'piix3', 'piix4' or 'ich6'. Those will be
needed to allow setting IDE controller model in VirtualBox driver.

They have to be unique within the domain. As usual, backwards
compatibility takes its price. In this particular situation we
have a device that is represented twice in a domain and so is its
alias.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Modify the allocation to be a real RWLockable object and add the
various RWLock{Read|Write} and RWUnlock calls to process the list
of interfaces.

For both virtio input devices and USB input devices.

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

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

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>

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>

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>