Currently, the CPU feature 'name' XML attribute, as in:

    [...]
    <cpu match='exact'>
      <model fallback='forbid'>IvyBridge</model>
      <vendor>Intel</vendor>
      <feature policy='require' name='pcid'/>
    </cpu>
    [...]

isn't explicitly documented in formatdomain.html.

Document it now.
Signed-off-by: NKashyap Chamarthy <kchamart@redhat.com>

Just like SRIOV, a PCI device is only capable of the mediated devices
framework when it's bound to the vendor native driver, thus if a driver
change occurs, e.g. vendor_native->vfio, we need to refresh some of the
device's capabilities to reflect the reality, mdev included.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Suggested-by: NWu Zongyong <cordius.wu@huawei.com>
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Now that we have all the building blocks in place, switch the nodedev
driver to use the "new" virMediatedDeviceType type instead of the "old"
virNodeDevCapMdevType one.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

These are not necessary anymore, since these are going to be shadowed by
the helpers provided by util/virmdev.c module.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

This is a replacement for the existing udevPCIGetMdevTypesCap which is
static to the udev backend. This simple helper constructs the sysfs path
from the device's base path for each mdev type and queries the
corresponding attributes of that type.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

This should serve as a replacement for the existing udevFillMdevType
which is responsible for fetching the device type's attributes from the
sysfs interface. The problem with the existing solution is that it's
tied to the udev backend.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

This is later going to replace the existing virNodeDevCapMdevType, since:
1) it's going to couple related stuff in a single module
2) util is supposed to contain helpers that are widely accessible across
the whole repository.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

There were some leftovers from early development which never got used.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Most of them are static, however in case of PCI and SCSI_HOST devices,
the nested capabilities can change dynamically, e.g. due to a driver
change (from host_pci_driver -> vfio_pci).
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Suggested-by: NWu Zongyong <cordius.wu@huawei.com>

Whether asking for a number of capabilities supported by a device or
listing them, it's handled essentially by a copy-paste code, so extract
the common stuff into this new helper which also updates all
capabilities just before touching them.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Since we moved the helpers from nodedev driver to src/conf, the actual
'update' function using those helpers should be moved as well so that we
don't need to call back into the driver.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

The capabilities are defined/parsed/formatted/queried from this module,
no reason for 'update' not being part of the module as well. This also
involves some module-specific prefix changes.
This patch also drops the node_device_linux_sysfs module from the repo
since:
a) it only contained the capability handlers we just moved
b) it's only linked with the driver (by design) and thus unreachable to
other modules
c) we touch sysfs across all the src/util modules so the module being
deleted hasn't been serving its original intention for some time already.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

We can call directly the virNodeDeviceGetSCSIHostCaps helper instead.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

This patch drops the capability matching redundancy by simply converting
the string input to our internal types which are then in turn used for
the actual capability matching.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

We currently have 2 methods that do the capability matching. This should
be condensed to a single function and all the derivates should just call
into that using a proper type conversion.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

We currently have 2 methods that do the capability matching. This should
be condensed to a single function and all the derivates should just call
into that using a proper type conversion.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

There is no method to rename inactive domains for test driver.
After this patch, we can rename the domains using 'domrename'.

    virsh# domrename test anothertest
    Domain successfully renamed
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

These test cases are supposed to verify GIC support works as
expected, and shouldn't concern themselves with other features;
we can trim them down significantly, and make them less likely
to need updating after unrelated changes.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

For vhost-user ports, Open vSwitch acts as the server and QEMU the client.
When OVS crashes or restarts, the QEMU process should be reconnected to
OVS.
Signed-off-by: NZhiPeng Lu <lu.zhipeng@zte.com.cn>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Missed adding the "encryption" description term entry to the list
of possible sub-elements for disk source. The description details
were there, just not the tag.

The flock() function and d_type field in struct dirent are not portable
to the mingw platform.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The virNetSocketWriteSASL method has to encode the buffer it is given and then
write it to the underlying socket. This write is not guaranteed to send the
full amount of data that was encoded by SASL. We cache the SASL encoded data so
that on the next invocation of virNetSocketWriteSASL we carry on sending it.

The subtle problem is that the 'len' value passed into virNetSocketWriteSASL on
the 2nd call may be larger than the original value. So when we've completed
sending the SASL encoded data we previously cached, we must return the original
length we encoded, not the new length.

This flaw means we could potentially have been discarded queued data without
sending it. This would have exhibited itself as a libvirt client never receiving
the reply to a method it invokes, async events silently going missing, or worse
stream data silently getting dropped.

For this to be a problem libvirtd would have to be queued data to send to the
client, while at the same time the TCP socket send buffer is full (due to a very
slow client). This is quite unlikely so if this bug was ever triggered by a real
world user it would be almost impossible to reproduce or diagnose, if indeed it
was ever noticed at all.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

During migration, the lock process is paused in the perform phase
but not resumed if there is a subsequent failure, leaving the locked
resource unprotected.

The perform phase itself can fail, in which case the lock process
should be resumed before returning from perform. The finish phase
could also fail on the destination host, in which case the migration
is canceled in the confirm phase and the VM is resumed. The lock
process needs to be resumed there as well.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Basically the `cpus` and `tasks` files are not needed, and I've witnessed on a
real system that the schemata file may have spaces prepended to a line, so let's
adjust at least one test so that it reflects what can happen.  Also `000`
allocation is invalid and a full mask means it's all free.  So adjust for that
too.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

We've been building up to this.  This adds support for cputune/cachetune
settings for domains in the QEMU driver.  The addition into
qemuProcessSetupVcpu() automatically adds support for hotplug.  For hot-unplug
we need to remove the allocation only if all the vCPUs were unplugged.  But
since the threads are left running, we can't really do much about it now.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1289368Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This test initializes capabilities from vircaps2xmldata (since it exists there
already) and then requests list of free bitmaps (all unallocated space) from
virresctrl.c

Desirable outputs are saved in virresctrldata.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

More info in the documentation, this is basically the XML parsing/formatting
support, schemas, tests and documentation for the new cputune/cachetune element
that will get used by following patches.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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>

Signed-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>

Just to ease the review of following patches.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Unfortunately, we have a number of aliases in virsh and even though
these are not visible any more, we have to support them. The problem is
that when trying to print help for the alias, we get SIGSEGV because
there isn't any @def structure anymore and we need to query the command
being aliased instead.

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

These helpers are called from a single place only - cmdHelp wrapper and
just before the wrapper invokes the helpers, it performs the search,
either for command group or for the command itself, except the result is
discarded and the helper therefore needs to do it again. Drop this
inefficient handling and pass the @def structure rather than a name,
thus preventing the helper from needing to perform the search again.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

This wires up the previously added OEM strings XML schema to be able to
generate comamnd line args for QEMU. This requires QEMU >= 2.12 release
containing this patch:

  commit 2d6dcbf93fb01b4a7f45a93d276d4d74b16392dd
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Sat Oct 28 21:51:36 2017 +0100

    smbios: support setting OEM strings table
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The OEM strings table in SMBIOS allows the vendor to pass arbitrary
strings into the guest OS. This can be used as a way to pass data to an
application like cloud-init, or potentially as an alternative to the
kernel command line for OS installers where you can't modify the install
ISO image to change the kernel args.

As an example, consider if cloud-init and anaconda supported OEM strings
you could use something like

    <oemStrings>
      <entry>cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/</entry>
      <entry>anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os</entry>
    </oemStrings>

use of a application specific prefix as illustrated above is
recommended, but not mandated, so that an app can reliably identify
which of the many OEM strings are targetted at it.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

We can start qemu with a "cpu,+la57" to set 57-bit vitrual address
space. So VM can be aware that it need to enable 5-level paging.

Corresponding QEMU commits:
        al57 6c7c3c21f95dd9af8a0691c0dd29b07247984122

Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>