The virresctrl will use this as well and we need to have that info after restart
to properly clean up /sys/fs/resctrl.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Due to confusing naming the pointer to the mask got copied which must not
happen, so use UpdateMask instead of SetMask.  That also means we can get
completely rid of SetMask.

Also don't clear the free bits since it is not used again (leftover from
previous versions).
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Introduce virResctrlAllocCopyMasks() and use that to initially copy the default
group schemata to the allocation before reserving any parts of the cache.  The
reason for this is that when new group is created the schemata will have unknown
data in it.  If there was previously group with the same CLoS ID, it will have
the previous valies, if not it will have all bits set.  And we need to set all
unspecified (in the XML) allocations to the same one as the default group.

Some non-Linux functions now need to be made public due to this change.

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

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

While the QEMU QAPI schema describes 'lun' as a number, the code dealing
with JSON strings does not strictly adhere to this schema and thus
formats the number back as a string. Use the new helper to retrieve both
possibilities.

Note that the formatting code is okay and qemu will accept it as an int.

Tweak also one of the test strings to verify that both formats work
with libvirt.

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

The helper is useful in cases when the JSON we have to parse may contain
one of the two due to historical reasons and the number value itself
would be stored as a string.

The <capabilities> feature has an attribute named 'policy', but the
error message mentioned the non-existing 'state' attribute instead.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Commit 000e9504 tried to fix improper bracketing when refreshing disk
volume stats for a backing volume. Unfortunately the condition is still
wrong as in cases as the backing store being inaccessible
storageBackendUpdateVolTargetInfo returns -2 if instructed to ignore
errors. The condition does not take this into account.

Dumping XML of a volume which has inacessible backing store would then
result into:

 # virsh vol-dumpxml http.img --pool default
 error: An error occurred, but the cause is unknown

Properly ignore -2 for backing volumes.

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

We are skipping non-directories under /sys/fs/resctrl/(info/) since those are not
interesting for us.  However in tests it can sometimes happen that ent->d_type
is 0 instead of 4 (DT_DIR) for directories.

I've seen it fail on two machines.  Different machines, different systems, I
cannot reproduce it even using the same setup.  So one of the ways how to work
around this is call stat() on it.  The other one is not checking if it is a
directory since we'll find out eventually when we want to read some files
underneath it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

This wil be used in the future, but it makes sense for now as well.  It makes
sure there is no mask leftover that would leak.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Pointed out during review on one or two places, but it actually appears in lot
more places.  So let's be consistent.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

When working on the CAT series one of the changes was that the pointer got
allocated in another part of the code, even when resctrl was not available on
the host system.  However this one particular place neglected that so it needs
to be fixed in order to get the proper error message when requesting
<cachetune/> on HW with no support for it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Commits f83c7c88 and 6eb1f2b9 broke the build on FreeBSD and OSX because
of symbols being undefined for those platforms.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

After processing the processEvent->data for a qemuProcessEventHandler
callout, it's expected that the called processEvent->eventType helper
will perform the proper free on the data field. In this case it's
a qemuMonitorEventPanicInfoPtr.

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>