[libvirt] [PATCH 00/12] qemu: Enforce guest CPU specification
by Jiri Denemark
When starting a domain with custom guest CPU specification QEMU may add
or remove some CPU features. There are several reasons for this, e.g.,
QEMU/KVM does not support some requested features or the definition of
the requested CPU model in libvirt's cpu_map.xml differs from the one
QEMU is using. We can't really avoid this because CPU models are allowed
to change with machine types and libvirt doesn't know (and probably
doesn't even want to know) about such changes.
Thus when we want to make sure guest ABI doesn't change when a domain
gets migrated to another host, we need to update our live CPU definition
according to the CPU QEMU created. Once updated, we will change CPU
checking to VIR_CPU_CHECK_FULL to make sure the virtual CPU created
after migration exactly matches the one on the source.
https://bugzilla.redhat.com/show_bug.cgi?id=822148
https://bugzilla.redhat.com/show_bug.cgi?id=824989
Jiri Denemark (12):
tests: Switch to sparse initialization of virCPUDef
docs: Clarify /domain/cpu/@match description
Introduce /domain/cpu/@check XML attribute
qemu: Set default values for CPU check attribute
qemu: Refactor Hyper-V features check
qemu: Refactor KVM features check
qemu: Refactor CPU features check
qemu: Refactor qemuProcessVerifyGuestCPU
qemu: Use ARCH_IS_X86 in qemuMonitorJSONGetGuestCPU
qemu: Ask QEMU for filtered CPU features
qemu: Update CPU definition according to QEMU
qemu: Enforce guest CPU specification
docs/formatdomain.html.in | 52 ++++-
docs/schemas/cputypes.rng | 10 +
docs/schemas/domaincommon.rng | 3 +
src/conf/cpu_conf.c | 30 +++
src/conf/cpu_conf.h | 12 ++
src/conf/domain_conf.c | 21 ++
src/cpu/cpu.c | 45 +++++
src/cpu/cpu.h | 12 ++
src/cpu/cpu_x86.c | 105 ++++++++++
src/libvirt_private.syms | 1 +
src/qemu/qemu_domain.c | 42 ++++
src/qemu/qemu_monitor.c | 11 +-
src/qemu/qemu_monitor.h | 3 +-
src/qemu/qemu_monitor_json.c | 38 +++-
src/qemu/qemu_monitor_json.h | 3 +-
src/qemu/qemu_process.c | 225 +++++++++++++--------
tests/domaincapstest.c | 38 ++--
tests/qemumonitorjsontest.c | 4 +-
.../qemuxml2argv-aarch64-gic-host.xml | 2 +-
.../qemuxml2argv-aarch64-gic-v2.xml | 2 +-
.../qemuxml2argv-aarch64-gic-v3.xml | 2 +-
.../qemuxml2argv-cpu-check-default-none.args | 21 ++
.../qemuxml2argv-cpu-check-default-none.xml | 19 ++
.../qemuxml2argv-cpu-check-default-none2.args | 21 ++
.../qemuxml2argv-cpu-check-default-none2.xml | 21 ++
.../qemuxml2argv-cpu-check-default-partial.args | 22 ++
.../qemuxml2argv-cpu-check-default-partial.xml | 19 ++
.../qemuxml2argv-cpu-check-default-partial2.args | 21 ++
.../qemuxml2argv-cpu-check-default-partial2.xml | 21 ++
.../qemuxml2argv-cpu-check-full.args | 1 +
.../qemuxml2argv-cpu-check-full.xml | 21 ++
.../qemuxml2argv-cpu-check-none.args | 21 ++
.../qemuxml2argv-cpu-check-none.xml | 21 ++
.../qemuxml2argv-cpu-check-partial.args | 1 +
.../qemuxml2argv-cpu-check-partial.xml | 21 ++
tests/qemuxml2argvtest.c | 8 +
.../qemuxml2xmlout-aarch64-aavmf-virtio-mmio.xml | 2 +-
...qemuxml2xmlout-aarch64-video-virtio-gpu-pci.xml | 2 +-
.../qemuxml2xmlout-aarch64-virtio-pci-default.xml | 2 +-
...2xmlout-aarch64-virtio-pci-manual-addresses.xml | 2 +-
.../qemuxml2xmlout-cpu-check-default-none.xml | 28 +++
.../qemuxml2xmlout-cpu-check-default-none2.xml | 30 +++
.../qemuxml2xmlout-cpu-check-default-partial.xml | 30 +++
.../qemuxml2xmlout-cpu-check-default-partial2.xml | 30 +++
.../qemuxml2xmlout-cpu-check-full.xml | 30 +++
.../qemuxml2xmlout-cpu-check-none.xml | 30 +++
.../qemuxml2xmlout-cpu-check-partial.xml | 30 +++
.../qemuxml2xmlout-cpu-eoi-disabled.xml | 2 +-
.../qemuxml2xmlout-cpu-eoi-enabled.xml | 2 +-
.../qemuxml2xmlout-cpu-host-kvmclock.xml | 2 +-
.../qemuxml2xmlout-cpu-host-model-features.xml | 2 +-
...emuxml2xmlout-cpu-host-passthrough-features.xml | 2 +-
.../qemuxml2xmlout-cpu-kvmclock.xml | 2 +-
.../qemuxml2xmlout-graphics-spice-timeout.xml | 2 +-
tests/qemuxml2xmltest.c | 8 +
tests/testutilsqemu.c | 48 ++---
56 files changed, 1039 insertions(+), 167 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-none.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-none.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-none2.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-none2.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-partial.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-partial.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-partial2.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-partial2.xml
create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-full.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-full.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-none.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-none.xml
create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-partial.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-partial.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-default-none.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-default-none2.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-default-partial.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-default-partial2.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-full.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-none.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-partial.xml
--
2.12.0
8 years
[libvirt] [PATCH 0/4] qemu: fix handling of 'group_name' disk io tuning parameter
by Peter Krempa
Fix a crasher and an invalid configuration.
Peter Krempa (4):
qemu: Don't steal pointers from 'persistentDef' in
qemuDomainGetBlockIoTune
qemu: command: Extract blkdeviotune checks into a separate function
qemu: command: Extract tests for subsets of blkdeviotune settings
qemu: command: Don't allow setting 'group_name' alone
src/qemu/qemu_command.c | 181 ++++++++++++++++++++++++++++++------------------
src/qemu/qemu_driver.c | 22 ++++--
2 files changed, 127 insertions(+), 76 deletions(-)
--
2.12.0
8 years
[libvirt] Failure to probe cpu definitions for e.g. qemu-system-mips
by Guido Günther
Hi,
while looking into a regression failing to start any mips qemu systems
(http://bugs.debian.org/854125) I noticed that querying cpu definition
does not work for lots of non intel architectures like mips due to lack
of support for the query-cpu-definition monitor command:
2017-03-15 04:23:55.336+0000: 4238: warning : virQEMUCapsLogProbeFailure:4838 : Failed to probe capabilities for /usr/bin/qemu-system-mips: internal error: unable to execute QEMU command 'query-cpu-definitions': The command query-cpu-definitions has not been found
2017-03-15 04:23:55.374+0000: 4238: error : qemuMonitorJSONCheckError:387 : internal error: unable to execute QEMU command 'query-cpu-definitions': The command query-cpu-definitions has not been found
Is support for query-cpu-definition a hard requirement or should we fail
gracefully in this case? If not I can look into restoring that
behaviour but would be happy about pointers what would be the best way
forward.
Cheers,
-- Guido
8 years
[libvirt] [PATCH] perf: remote: Compare perf nparams against the correct constant
by Nitesh Konkar
Currently 'virsh perf domain' errors out as the perf nparams is
incorrectly compared against REMOTE_DOMAIN_MEMORY_PARAMETERS_MAX
instead of REMOTE_DOMAIN_PERF_EVENTS_MAX.
Signed-off-by: Nitesh Konkar <nitkon12(a)linux.vnet.ibm.com>
---
daemon/remote.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/daemon/remote.c b/daemon/remote.c
index f2b9b9a..1c9708c 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -3105,7 +3105,7 @@ remoteDispatchDomainGetPerfEvents(virNetServerPtr server ATTRIBUTE_UNUSED,
if (virDomainGetPerfEvents(dom, ¶ms, &nparams, args->flags) < 0)
goto cleanup;
- if (nparams > REMOTE_DOMAIN_MEMORY_PARAMETERS_MAX) {
+ if (nparams > REMOTE_DOMAIN_PERF_EVENTS_MAX) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams too large"));
goto cleanup;
}
--
1.9.3
8 years
[libvirt] [PATCH] vz: Remove unused variable
by Mikhail Feoktistov
emulatedType is not used in prlsdkAddDomainHardDisksInfo()
---
src/vz/vz_sdk.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
index 3fd17db..8e6e89d 100644
--- a/src/vz/vz_sdk.c
+++ b/src/vz/vz_sdk.c
@@ -817,14 +817,9 @@ prlsdkAddDomainHardDisksInfo(vzDriverPtr driver, PRL_HANDLE sdkdom, virDomainDef
for (i = 0; i < hddCount; ++i) {
- PRL_UINT32 emulatedType;
-
pret = PrlVmCfg_GetHardDisk(sdkdom, i, &hdd);
prlsdkCheckRetGoto(pret, error);
- pret = PrlVmDev_GetEmulatedType(hdd, &emulatedType);
- prlsdkCheckRetGoto(pret, error);
-
if (IS_CT(def) &&
prlsdkInBootList(sdkdom, hdd)) {
--
1.8.3.1
8 years
[libvirt] [PATCH] apparmor: allow /usr/lib/qemu/qemu-bridge-helper
by Guido Günther
This is where e.g. Debian puts it.
---
examples/apparmor/usr.sbin.libvirtd | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd
index 8893e75fe..03a80b7e6 100644
--- a/examples/apparmor/usr.sbin.libvirtd
+++ b/examples/apparmor/usr.sbin.libvirtd
@@ -67,7 +67,7 @@
# allow changing to our UUID-based named profiles
change_profile -> @{LIBVIRT}-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*,
- /usr/{lib,libexec}/qemu-bridge-helper Cx -> qemu_bridge_helper,
+ /usr/{lib,lib/qemu,libexec}/qemu-bridge-helper Cx -> qemu_bridge_helper,
# child profile for bridge helper process
profile qemu_bridge_helper {
#include <abstractions/base>
--
2.11.0
8 years
[libvirt] [PATCH 1/1] perf: list all supported events when get domain stats
by Qiaowei Ren
Currently when virDomainListGetStats is called, the stats for those
disabled perf events won't be showed in result. This will produce
some problems for applications based on libvirt sometime, e.g. the
OpenStack bug https://bugs.launchpad.net/ceilometer/+bug/1670948
This patch just show '0' in result for disabled events for
virDomainListGetStats API. I guess this should be also rational to
show all stats even though the events are not enabled.
Signed-off-by: Qiaowei Ren <qiaowei.ren(a)intel.com>
---
src/qemu/qemu_driver.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 2032fac..237bf57 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -19355,8 +19355,10 @@ qemuDomainGetStatsPerfOneEvent(virPerfPtr perf,
char param_name[VIR_TYPED_PARAM_FIELD_LENGTH];
uint64_t value = 0;
- if (virPerfReadEvent(perf, type, &value) < 0)
- return -1;
+ if (virPerfEventIsEnabled(perf, type)) {
+ if (virPerfReadEvent(perf, type, &value) < 0)
+ return -1;
+ }
snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, "perf.%s",
virPerfEventTypeToString(type));
@@ -19383,9 +19385,6 @@ qemuDomainGetStatsPerf(virQEMUDriverPtr driver ATTRIBUTE_UNUSED,
int ret = -1;
for (i = 0; i < VIR_PERF_EVENT_LAST; i++) {
- if (!virPerfEventIsEnabled(priv->perf, i))
- continue;
-
if (qemuDomainGetStatsPerfOneEvent(priv->perf, i,
record, maxparams) < 0)
goto cleanup;
--
1.9.1
8 years
[libvirt] limit cpu speed in domain xml
by Vasiliy Tolstov
Hi. Does it possible to limit vm cpu speed for example to 1Ghz or 500Mhz ?
I need to simulate some hardware with specific cpu speed and test my
application inside this vm , i want to measure results from each test
and need constant cpu speed for testing (i need to run test not only
my notebook but on server too and want identical cpu speed inside vm)
--
Vasiliy Tolstov,
e-mail: v.tolstov(a)selfip.ru
8 years
[libvirt] libvirt-python bug: custom event loop impl calls ff callback from *Remove(Handle|Timeout)Func
by Wojtek Porczyk
Hello libvirt-list,
As of current libvirt-python.git, according to libvirt-override.c, if
implementing custom event loop in Python, ff callback is called from
libvirt_virEventRemoveHandleFunc, which is a C glue between
virEventRegisterImpl and actual removeHandle function written in Python:
> result = PyEval_CallObject(removeHandleObj, pyobj_args);
> if (!result) {
> PyErr_Print();
> PyErr_Clear();
> } else if (!PyTuple_Check(result) || PyTuple_Size(result) != 3) {
> DEBUG("%s: %s must return opaque obj registered with %s"
> "to avoid leaking libvirt memory\n",
> __FUNCTION__, NAME(removeHandle), NAME(addHandle));
> } else {
> opaque = PyTuple_GetItem(result, 1);
> ff = PyTuple_GetItem(result, 2);
> cff = PyvirFreeCallback_Get(ff);
> if (cff)
> (*cff)(PyvirVoidPtr_Get(opaque));
> retval = 0;
> }
This is exactly what one shoud not be doing according to documentation [1]:
> If the opaque user data requires free'ing when the handle is unregistered,
> then a 2nd callback can be supplied for this purpose. This callback needs to
> be invoked from a clean stack. If 'ff' callbacks are invoked directly from the
> virEventRemoveHandleFunc they will likely deadlock in libvirt.
[1] https://libvirt.org/html/libvirt-libvirt-event.html#virEventAddHandleFunc
This is true, the deadlock occurs. When the "result" tuple is mangled to have
None as third item ("ff"), then cff = PyvirFreeCallback_Get(ff) is NULL and
the deadlock does not happen.
That's also why script examples/event-test.py does not deadlock, because it
does not return anything (that is, returns None) from Python, so the second if
block happens and the ff callback, if any, is not executed (and probably
something leaks, but I didn't check for that).
Everything also applies to to timeouts (libvirt_virEventRemoteTimeoutFunc).
--
pozdrawiam / best regards _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers, | '-.-' |
I fear lack of them. '-._ : ,-'
-- Isaac Asimov `^-^-_>
8 years
