[libvirt] [PATCH 00/11] hyperv: add support for Hyper-V 2012 and newer.
by Dawid Zamirski
Hello,
The following patch series reworks the hyper-v driver structs and the
code generator to provide seamless support for both Hyper-V 2008 and
2012 or newer. This does not implement any new libvirt APIs, it just
adapts existing 2008-only driver to also handle 2012 and newer by
sharing as much driver code as possible (currently it's all of it :-))
This is needed to set the foundation before we can move forward with
implementing the rest of the driver APIs.
With 2012 release, Microsoft introduced "v2" version of Msvm_* WMI
classes. Those are largely the same as "v1" (used in 2008) but have some
new properties as well as need different wsman request URIs. To
accomodate those differences, most of work went into the code generator
so that it's "aware" of possibility of multiple versions of the same WMI
class and produce C code accordingly.
To accomplish this the following changes were made:
* hypervPrivate has now wmiVersion field so the driver can check this
at runtime and take appropiate action as needed.
* the abstract hypervObject struct's data member was changed to a union
that has "common", "v1" and "v2" members. Those are structs that
represent WMI classes that we get back from wsman response. The
"common" struct has members that are present in both "v1" and "v2"
which the driver API callbacks can use to read the data from in
version-independent manner (if version-specific member needs to be
accessed the driver can check priv->wmiVersion and read from "v1" or
"v2" as needed). Those structs are guaranteed to be memory aligned
by the code generator (see the _align_propert_members implementation
that takes care of that)
* the generator produces *_WmiInfo for each WMI class "family" that
holds an array of hypervWmiClassInfoPtr each providing information
as to which request URI to use for each "version" of given WMI class
as well as XmlSerializerInfo struct needed to unserilize wsman
responsed into the data structs. The driver uses those to make proper
wsman request depending on which version it's connected to.
* the generator no longer produces "helper" functions such as
hypervGetMsvmComputerSystemList as those were originally just simple
wrappers around hypervEnumAndPull, instead those were hand-written
now (to keep driver changes minimal). The reason is that we'll have
more code coming (once/if this get ACK) implementing missing libvirt
APIs and surely code patterns will emerge that would warrant more
useful "utility" functions like that.
* a hypervInitConnection was added to the driver which "detects"
hyper-v version by testing simple wsman request using v2 then falling
back to v1, obviously if both fail, the we're erroring out.
To express how the above translates in code:
int
hypervImplementSomeLibvirtApi(virConnectPtr conn, ...)
{
hypervPrivate *priv = conn->privateData;
hypervWqlQuery wqlQuery = HYPERV_WQL_QUERY_INITIALIZER;
Msvm_ComputerSystem *list = NULL; /* typed hypervObject instance */
/* the WmiInfo struct has the data needed for wsman request and
* response handling for both v1 and v2 */
wqlQuery.info = Msvm_ComputerSystem_WmiInfo;
wqlQuery.query = "select * from Msvm_ComputerSystem";
if (hypervEnumAndPull(priv, &query, (hypervObject **) &list) < 0) {
goto cleanup;
}
if (list == NULL) {
/* none found */
goto cleanup;
}
/* works with v1 and v2 */
char *vmName = list->data.common->Name;
/* access property that is in v2 only */
if (priv->wmiVersion == HYPERV_WMI_VERSION_V2)
char *foo = list->data.v2->V2Property;
else
char *foo = list->data.v1->V1Property;
}
Dawid Zamirski (11):
hyperv: fixed typo in function name.
hyperv: store WMI version in hypervPrivate.
hyperv: introduce hypervWmiClassInfo struct.
hyperv: update hypervObject struct.
hyperv: add hypervWqlQuery struct.
hyperv: make hypervEnumAndPull use hypervWqlQuery
hyperv: update generator input file.
hyperv: update wmi code generator.
hyperv: add helper for getting WMI class lists.
hyperv: port rest of the driver to new stucts.
hyperv: add hypervInitConnection.
src/Makefile.am | 2 -
src/hyperv/hyperv_driver.c | 168 ++++++++------
src/hyperv/hyperv_private.h | 8 +-
src/hyperv/hyperv_wmi.c | 179 +++++++++++----
src/hyperv/hyperv_wmi.h | 58 ++++-
src/hyperv/hyperv_wmi_classes.h | 30 +++
src/hyperv/hyperv_wmi_generator.input | 239 +++++++++++++++++---
src/hyperv/hyperv_wmi_generator.py | 409 +++++++++++++++++++++++-----------
8 files changed, 809 insertions(+), 284 deletions(-)
mode change 100755 => 100644 src/hyperv/hyperv_wmi_generator.py
--
2.9.3
7 years, 12 months
[libvirt] [PATCH] Document virDomainAbortJob behavior for post-copy migration
by Jiri Denemark
https://bugzilla.redhat.com/show_bug.cgi?id=1389313
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
src/libvirt-domain.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
index 26da0e7f3..4670c54e5 100644
--- a/src/libvirt-domain.c
+++ b/src/libvirt-domain.c
@@ -8702,7 +8702,9 @@ virDomainGetJobStats(virDomainPtr domain,
* @domain: a domain object
*
* Requests that the current background job be aborted at the
- * soonest opportunity.
+ * soonest opportunity. In case the job is a migration in a post-copy mode,
+ * virDomainAbortJob will report an error (see virDomainMigrateStartPostCopy
+ * for more details).
*
* Returns 0 in case of success and -1 in case of failure.
*/
@@ -8976,7 +8978,8 @@ virDomainMigrateGetMaxSpeed(virDomainPtr domain,
* rolled back because none of the hosts has complete state. If this happens,
* libvirt will leave the domain paused on both hosts with
* VIR_DOMAIN_PAUSED_POSTCOPY_FAILED reason. It's up to the upper layer to
- * decide what to do in such case.
+ * decide what to do in such case. Because of this, libvirt will refuse to
+ * cancel post-copy migration via virDomainAbortJob.
*
* The following domain life cycle events are emitted during post-copy
* migration:
--
2.12.0
7 years, 12 months
[libvirt] libvirtd not responding to virsh, results in virsh hanging
by Chris Friesen
Hi,
We've recently run into an issue with libvirt 1.2.17 in the context of an
OpenStack deployment.
Occasionally after doing live migrations from a compute node with libvirt 1.2.17
to a compute node with libvirt 2.0.0 we see libvirtd on the 1.2.17 side stop
responding. When this happens, if you run a command like "sudo virsh list" then
it just hangs waiting for a response from libvirtd.
Running "ps -elfT|grep libvirtd" shows many threads waiting on a futex, but two
threads in poll_schedule_timeout() as part of the poll() syscall. On a non-hung
libvirtd I only see one thread in poll_schedule_timeout().
If I kill and restart libvirtd (this took two tries, it didn't actually die the
first time) then the problem seems to go away.
I just tried attaching gdb to the "hung" libvirtd process and running "thread
apply all backtrace". This printed backtraces for the threads, including the
one that was apparently stuck in poll():
Thread 17 (Thread 0x7f0573fff700 (LWP 186865)):
#0 0x00007f05b59d769d in poll () from /lib64/libc.so.6
#1 0x00007f05b7f01b9a in virNetClientIOEventLoop () from /lib64/libvirt.so.0
#2 0x00007f05b7f0234b in virNetClientSendInternal () from /lib64/libvirt.so.0
#3 0x00007f05b7f036f3 in virNetClientSendWithReply () from /lib64/libvirt.so.0
#4 0x00007f05b7f04eb3 in virNetClientStreamSendPacket () from /lib64/libvirt.so.0
#5 0x00007f05b7ed8db5 in remoteStreamFinish () from /lib64/libvirt.so.0
#6 0x00007f05b7ec7eaa in virStreamFinish () from /lib64/libvirt.so.0
#7 0x00007f059bd9323d in qemuMigrationIOFunc () from
/usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so
#8 0x00007f05b7e09aa2 in virThreadHelper () from /lib64/libvirt.so.0
#9 0x00007f05b5cb4dc5 in start_thread () from /lib64/libpthread.so.0
#10 0x00007f05b59e1ced in clone () from /lib64/libc.so.6
Interestingly, when I hit "c" to continue in the debugger, I got this:
(gdb) c
Continuing.
Program received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x7f0573fff700 (LWP 186865)]
0x00007f05b5cbb1cd in write () from /lib64/libpthread.so.0
(gdb) c
Continuing.
[Thread 0x7f0573fff700 (LWP 186865) exited]
(gdb) quit
A debugging session is active.
Inferior 1 [process 37471] will be detached.
Quit anyway? (y or n) y
Detaching from program: /usr/sbin/libvirtd, process 37471
Now thread 186865 seems to be gone, and libvirtd is no longer hung.
Has anyone seen anything like this before? Anyone have an idea where to start
looking?
Thanks,
Chris
7 years, 12 months
[libvirt] [PATCH 0/2] Don't kill domains on daemon restart
by Michal Privoznik
Patch 1/2 is just a cleanup; patch 2/2 fixes the actual issue.
Michal Privoznik (2):
virDomainDiskDefForeachPath: Prefer virStorageSourceIsLocalStorage
Introduce and use virDomainDiskZeroSource
src/conf/domain_conf.c | 27 ++++++++++++++++++++++++---
src/conf/domain_conf.h | 1 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_domain.c | 2 +-
src/qemu/qemu_process.c | 2 +-
src/vmx/vmx.c | 6 +++---
src/xenconfig/xen_xm.c | 2 +-
7 files changed, 32 insertions(+), 9 deletions(-)
--
2.10.2
7 years, 12 months
[libvirt] [PATCH 00/16] Expose host cache information in capabilities
by Martin Kletzander
I think thanks to previous patches regarding sysfs, this should be
very easy to review. The XML snippet that shows how the capablity XML
looks like can be seen in the second to last patch which adds test
for it.
Again, first few patches are trivial because I couldn't be bothered to
split the branch in two and writing two cover letters and moreover
those are patches for trivialities I stumbled upon during the work on
this series.
Also, this series is based upon Peter's news.xml validation against
RNG schema:
https://www.redhat.com/archives/libvir-list/2017-March/msg01478.html
Previous discussion threads on the XML design and patches touching
this topic can be found here (not meant to be a complete list):
https://www.redhat.com/archives/libvir-list/2017-January/msg00354.html
https://www.redhat.com/archives/libvir-list/2017-January/msg00512.html
https://www.redhat.com/archives/libvir-list/2017-January/msg00633.html
https://www.redhat.com/archives/libvir-list/2017-February/msg00777.html
https://www.redhat.com/archives/libvir-list/2017-March/msg00197.html
Martin Kletzander (16):
conf: Fix possible memleak in capabilities
util: Fix virDirRead() description
virsysfs: Add comments to separate logical blocks of functions
util: Add virStringTrimOptionalNewline
util: Add virFileReadValueScaledInt
util: Add virSysfsDirOpen
util: Add virSysfsCpuDirOpen
util: Use virStringTrimOptionalNewline in virFileRead*
util: Unify behaviour of the functions in sysfs.c
util: Add virSysfsGetCPUCache* functions
tests: Test capability XMLs in vircaps2xmldata
Add RNG schema for host cache information in capabilities
Add host cache information into capabilities
tests: Add missing cache data for vircaps2xmltest
tests: Add tests for caches into vircaps2xmltest
Init host cache info in drivers
docs/schemas/capability.rng | 34 +++++
src/conf/capabilities.c | 162 ++++++++++++++++++++-
src/conf/capabilities.h | 29 ++++
src/libvirt_private.syms | 9 ++
src/lxc/lxc_conf.c | 3 +
src/openvz/openvz_conf.c | 3 +
src/phyp/phyp_driver.c | 3 +
src/qemu/qemu_capabilities.c | 3 +
src/uml/uml_conf.c | 3 +
src/util/virfile.c | 50 +++++--
src/util/virfile.h | 1 +
src/util/virhostcpu.c | 4 +-
src/util/virstring.h | 8 +
src/util/virsysfs.c | 162 +++++++++++++++++++--
src/util/virsysfs.h | 56 +++++++
src/vbox/vbox_common.c | 3 +
src/vmware/vmware_conf.c | 3 +
src/vz/vz_driver.c | 2 +
.../linux-caches/cpu/cpu0/cache/index0/id | 1 +
.../cpu/cpu0/cache/index0/shared_cpu_list | 2 +-
.../cpu/cpu0/cache/index0/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu0/cache/index1/id | 1 +
.../cpu/cpu0/cache/index1/shared_cpu_list | 2 +-
.../cpu/cpu0/cache/index1/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu0/cache/index2/id | 1 +
.../cpu/cpu0/cache/index2/shared_cpu_list | 2 +-
.../cpu/cpu0/cache/index2/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu0/cache/index3/id | 1 +
.../linux-caches/cpu/cpu1/cache/index0/id | 1 +
.../cpu/cpu1/cache/index0/shared_cpu_list | 2 +-
.../cpu/cpu1/cache/index0/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu1/cache/index1/id | 1 +
.../cpu/cpu1/cache/index1/shared_cpu_list | 2 +-
.../cpu/cpu1/cache/index1/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu1/cache/index2/id | 1 +
.../cpu/cpu1/cache/index2/shared_cpu_list | 2 +-
.../cpu/cpu1/cache/index2/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu1/cache/index3/id | 1 +
.../linux-caches/cpu/cpu2/cache/index0/id | 1 +
.../cpu/cpu2/cache/index0/shared_cpu_list | 2 +-
.../cpu/cpu2/cache/index0/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu2/cache/index1/id | 1 +
.../cpu/cpu2/cache/index1/shared_cpu_list | 2 +-
.../cpu/cpu2/cache/index1/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu2/cache/index2/id | 1 +
.../cpu/cpu2/cache/index2/shared_cpu_list | 2 +-
.../cpu/cpu2/cache/index2/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu2/cache/index3/id | 1 +
.../linux-caches/cpu/cpu3/cache/index0/id | 1 +
.../cpu/cpu3/cache/index0/shared_cpu_list | 2 +-
.../cpu/cpu3/cache/index0/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu3/cache/index1/id | 1 +
.../cpu/cpu3/cache/index1/shared_cpu_list | 2 +-
.../cpu/cpu3/cache/index1/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu3/cache/index2/id | 1 +
.../cpu/cpu3/cache/index2/shared_cpu_list | 2 +-
.../cpu/cpu3/cache/index2/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu3/cache/index3/id | 1 +
.../linux-caches/cpu/cpu4/cache/index0/id | 1 +
.../cpu/cpu4/cache/index0/shared_cpu_list | 2 +-
.../cpu/cpu4/cache/index0/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu4/cache/index1/id | 1 +
.../cpu/cpu4/cache/index1/shared_cpu_list | 2 +-
.../cpu/cpu4/cache/index1/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu4/cache/index2/id | 1 +
.../cpu/cpu4/cache/index2/shared_cpu_list | 2 +-
.../cpu/cpu4/cache/index2/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu4/cache/index3/id | 1 +
.../linux-caches/cpu/cpu5/cache/index0/id | 1 +
.../cpu/cpu5/cache/index0/shared_cpu_list | 2 +-
.../cpu/cpu5/cache/index0/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu5/cache/index1/id | 1 +
.../cpu/cpu5/cache/index1/shared_cpu_list | 2 +-
.../cpu/cpu5/cache/index1/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu5/cache/index2/id | 1 +
.../cpu/cpu5/cache/index2/shared_cpu_list | 2 +-
.../cpu/cpu5/cache/index2/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu5/cache/index3/id | 1 +
.../linux-caches/cpu/cpu6/cache/index0/id | 1 +
.../cpu/cpu6/cache/index0/shared_cpu_list | 2 +-
.../cpu/cpu6/cache/index0/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu6/cache/index1/id | 1 +
.../cpu/cpu6/cache/index1/shared_cpu_list | 2 +-
.../cpu/cpu6/cache/index1/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu6/cache/index2/id | 1 +
.../cpu/cpu6/cache/index2/shared_cpu_list | 2 +-
.../cpu/cpu6/cache/index2/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu6/cache/index3/id | 1 +
.../linux-caches/cpu/cpu7/cache/index0/id | 1 +
.../cpu/cpu7/cache/index0/shared_cpu_list | 2 +-
.../cpu/cpu7/cache/index0/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu7/cache/index1/id | 1 +
.../cpu/cpu7/cache/index1/shared_cpu_list | 2 +-
.../cpu/cpu7/cache/index1/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu7/cache/index2/id | 1 +
.../cpu/cpu7/cache/index2/shared_cpu_list | 2 +-
.../cpu/cpu7/cache/index2/shared_cpu_map | 2 +-
.../linux-caches/cpu/cpu7/cache/index3/id | 1 +
tests/vircaps2xmldata/vircaps-x86_64-caches.xml | 15 ++
tests/vircaps2xmltest.c | 3 +-
tests/virschematest.c | 3 +-
101 files changed, 608 insertions(+), 79 deletions(-)
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu0/cache/index0/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu0/cache/index1/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu0/cache/index2/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu0/cache/index3/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu1/cache/index0/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu1/cache/index1/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu1/cache/index2/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu1/cache/index3/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu2/cache/index0/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu2/cache/index1/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu2/cache/index2/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu2/cache/index3/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu3/cache/index0/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu3/cache/index1/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu3/cache/index2/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu3/cache/index3/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu4/cache/index0/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu4/cache/index1/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu4/cache/index2/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu4/cache/index3/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu5/cache/index0/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu5/cache/index1/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu5/cache/index2/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu5/cache/index3/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu6/cache/index0/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu6/cache/index1/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu6/cache/index2/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu6/cache/index3/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu7/cache/index0/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu7/cache/index1/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu7/cache/index2/id
create mode 100644 tests/vircaps2xmldata/linux-caches/cpu/cpu7/cache/index3/id
--
2.12.2
7 years, 12 months
[libvirt] [PATCH 0/2] Two simple network improvements
by Michal Privoznik
The first is an improvement, the second is actually a bug fix.
Michal Privoznik (2):
networkUpdateState: Create virMacMap module more frequently
network: Don't crash on domain destroy
src/network/bridge_driver.c | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
--
2.11.0
7 years, 12 months
[libvirt] libvirt 2.3.0 and later versions hanging
by Paul Gildea
Hi, I am starting a libvritd process when booting up an embedded networking
system via python, like so:
subprocess.Popen(["libvirtd","-d"],stdout=subprocess.PIPE,stderr=subprocess.PIPE)
This runs and works fine for version 1.2.20. However after I upgraded to
2.3.0 I started noticing an intermittent bug. Sometimes my CLI will hang
when libvirtd is starting (most of the time it starts fine).
I ssh'd in and had a look around. libvirtd had a second process entry:
[root@trx-r2 log]# ps ax | grep libvirt
826 ? Sl 0:00 libvirtd -d
843 ? S 0:00 libvirtd -d
869 pts/0 S+ 0:00 grep libvirt
Using strace I could see the second entry was blocking (FUTEX). Kill
libvirtd processes and the boot continues as normal. I updated libvirt to
the latest version and this still happens. To confirm I downgraded to
1.2.20 again and everything works smoothly. Any idea of what may have
changed to cause this, pointers for me as to where to have a look?
Thanks,
--
Paul
7 years, 12 months
[libvirt] [PATCH V2 1/2] util: Add more virsysfs functions for handling resctrl sysfs
by Eli Qiao
Extended /sys/fs/resctrl sysfs handling.
Signed-off-by: Eli Qiao <liyong.qiao(a)intel.com>
---
src/libvirt_private.syms | 11 ++++-
src/util/virsysfs.c | 102 ++++++++++++++++++++++++++++++++++++++++++++++-
src/util/virsysfs.h | 16 ++++++++
src/util/virsysfspriv.h | 1 +
4 files changed, 128 insertions(+), 2 deletions(-)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index b551cb8..b03ad5b 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -2388,6 +2388,10 @@ virRandomGenerateWWN;
virRandomInt;
+# util/virresctrl.h
+virResCtrlAvailable;
+virResCtrlInit;
+
# util/virrotatingfile.h
virRotatingFileReaderConsume;
virRotatingFileReaderFree;
@@ -2626,13 +2630,18 @@ virSysfsGetCpuValueString;
virSysfsGetCpuValueUint;
virSysfsGetNodeValueBitmap;
virSysfsGetNodeValueString;
+virSysfsGetResctrlInfoString;
+virSysfsGetResctrlInfoUint;
+virSysfsGetResctrlPath;
+virSysfsGetResctrlString;
+virSysfsGetResctrlUint;
virSysfsGetSystemPath;
virSysfsGetValueBitmap;
virSysfsGetValueInt;
virSysfsGetValueString;
+virSysfsSetResctrlPath;
virSysfsSetSystemPath;
-
# util/virsysinfo.h
virSysinfoBaseBoardDefClear;
virSysinfoBIOSDefFree;
diff --git a/src/util/virsysfs.c b/src/util/virsysfs.c
index 7a98b48..97808be 100644
--- a/src/util/virsysfs.c
+++ b/src/util/virsysfs.c
@@ -36,8 +36,10 @@ VIR_LOG_INIT("util.sysfs");
#define VIR_SYSFS_VALUE_MAXLEN 8192
#define SYSFS_SYSTEM_PATH "/sys/devices/system"
+#define SYSFS_RESCTRL_PATH "/sys/fs/resctrl"
static const char *sysfs_system_path = SYSFS_SYSTEM_PATH;
+static const char *sysfs_resctrl_path = SYSFS_RESCTRL_PATH;
void virSysfsSetSystemPath(const char *path)
@@ -48,13 +50,26 @@ void virSysfsSetSystemPath(const char *path)
sysfs_system_path = SYSFS_SYSTEM_PATH;
}
-
const char *
virSysfsGetSystemPath(void)
{
return sysfs_system_path;
}
+void virSysfsSetResctrlPath(const char *path)
+{
+ if (path)
+ sysfs_resctrl_path = path;
+ else
+ sysfs_resctrl_path = SYSFS_RESCTRL_PATH;
+}
+
+const char *
+virSysfsGetResctrlPath(void)
+{
+ return sysfs_resctrl_path;
+}
+
int
virSysfsGetValueInt(const char *file,
int *value)
@@ -227,3 +242,88 @@ virSysfsGetNodeValueBitmap(unsigned int node,
VIR_FREE(path);
return ret;
}
+
+int
+virSysfsGetResctrlString(const char* file,
+ char **value)
+{
+ char *path = NULL;
+ int ret = -1;
+ if (virAsprintf(&path, "%s/%s", sysfs_resctrl_path, file) < 0)
+ return -1;
+
+ if (!virFileExists(path)) {
+ ret = -2;
+ goto cleanup;
+ }
+
+ if (virFileReadAll(path, VIR_SYSFS_VALUE_MAXLEN, value) < 0)
+ goto cleanup;
+
+ ret = 0;
+
+ cleanup:
+ VIR_FREE(path);
+ return ret;
+}
+
+int
+virSysfsGetResctrlUint(const char* file,
+ unsigned int *value)
+{
+ char *path = NULL;
+ int ret = -1;
+ if (virAsprintf(&path, "%s/%s", sysfs_resctrl_path, file) < 0)
+ return -1;
+
+ if (!virFileExists(path)) {
+ ret = -2;
+ goto cleanup;
+ }
+
+ ret = virFileReadValueUint(path, value);
+
+ cleanup:
+ VIR_FREE(path);
+ return ret;
+}
+
+int
+virSysfsGetResctrlInfoString(const char* file,
+ char **value)
+{
+ char *path = NULL;
+ int ret = -1;
+ if (virAsprintf(&path, "%s/info/%s", sysfs_resctrl_path, file) < 0)
+ return -1;
+
+ if (!virFileExists(path)) {
+ ret = -2;
+ goto cleanup;
+ }
+
+ if (virFileReadAll(path, VIR_SYSFS_VALUE_MAXLEN, value) < 0)
+ goto cleanup;
+
+ ret = 0;
+
+ cleanup:
+ VIR_FREE(path);
+ return ret;
+}
+
+int
+virSysfsGetResctrlInfoUint(const char *file,
+ unsigned int *value)
+{
+ char *path = NULL;
+ int ret = -1;
+
+ if (virAsprintf(&path, "%s/info/%s", sysfs_resctrl_path, file) < 0)
+ return -1;
+
+ ret = virFileReadValueUint(path, value);
+
+ VIR_FREE(path);
+ return ret;
+}
diff --git a/src/util/virsysfs.h b/src/util/virsysfs.h
index cd871ff..af1e786 100644
--- a/src/util/virsysfs.h
+++ b/src/util/virsysfs.h
@@ -25,6 +25,7 @@
# include "virbitmap.h"
const char * virSysfsGetSystemPath(void);
+const char * virSysfsGetResctrlPath(void);
int
virSysfsGetValueInt(const char *file,
@@ -67,4 +68,19 @@ virSysfsGetNodeValueBitmap(unsigned int cpu,
const char *file,
virBitmapPtr *value);
+int
+virSysfsGetResctrlString(const char* file,
+ char **value);
+
+int
+virSysfsGetResctrlUint(const char* file,
+ unsigned int *value);
+
+int
+virSysfsGetResctrlInfoString(const char* file,
+ char **value);
+
+int
+virSysfsGetResctrlInfoUint(const char *file,
+ unsigned int *value);
#endif /* __VIR_SYSFS_H__*/
diff --git a/src/util/virsysfspriv.h b/src/util/virsysfspriv.h
index ae9f54a..bf36082 100644
--- a/src/util/virsysfspriv.h
+++ b/src/util/virsysfspriv.h
@@ -24,5 +24,6 @@
# include "virsysfs.h"
void virSysfsSetSystemPath(const char *path);
+void virSysfsSetResctrlPath(const char *path);
#endif /* __VIR_SYSFS_PRIV_H__*/
--
1.9.1
7 years, 12 months
[libvirt] [PATCH] admin: Throw a system error when 'open' fails on user-provided output
by Erik Skultety
There was an unhandled 'open' call which resulted in:
"error: Library function returned error but did not set virError"
Even if this happens during the daemon's start when we still don't have
any set of outputs defined yet, we can safely report an error, since we
automatically fallback to stderr which is fine even for both
running as a daemonized process, since this happens before the daemon
forks into the background, and running as a systemd service, since
systemd re-directs std outputs to journald by default.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1436060
Signed-off-by: Erik Skultety <eskultet(a)redhat.com>
---
src/util/virlog.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/util/virlog.c b/src/util/virlog.c
index 7b584f8e37..7933e1a7a0 100644
--- a/src/util/virlog.c
+++ b/src/util/virlog.c
@@ -750,8 +750,10 @@ virLogNewOutputToFile(virLogPriority priority,
virLogOutputPtr ret = NULL;
fd = open(file, O_CREAT | O_APPEND | O_WRONLY, S_IRUSR | S_IWUSR);
- if (fd < 0)
+ if (fd < 0) {
+ virReportSystemError(errno, _("failed to open %s"), file);
return NULL;
+ }
if (!(ret = virLogOutputNew(virLogOutputToFd, virLogCloseFd,
(void *)(intptr_t)fd,
--
2.12.2
7 years, 12 months
[libvirt] [GSOC] project libvirt fuzzing
by Da L
Dear all,
This is my first post in the list.
I am currently a graduate student studying computer science, particularly
interested in visualization technologies and I have been using QEMU for a
variety of projects for a while. Two of the courses that I am taking this
semester really attracted me to the libvirt community are Advanced
Operating Systems and Secure Software Development. I have been learning
kernel fuzzing as well as other general fuzzing tools.
Then I found the topic of "QEMU command line generator XML fuzzing" is
pretty interesting and totally in line with my interest and background.
Though I have read through the documentations on the website, just to make
sure I am doing it correctly, could anyone confirm this project is still
available? And what I need to do next in order to participate the project
this summer? Do I need to find a mentor by myself? Potentially, I could
find my OS or Security professor as my mentor, but I am not sure yet which
would be the best way.
Thanks,
Dan
7 years, 12 months
