[libvirt] [PATCH v1 01/35] util: conf: add bootHash to virDomainParseTotalParam
by xinhua.Cao
add bootHash to virDomainParseTotalParam
---
src/conf/domain_conf.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 1e949ea..1a8248d 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -18516,6 +18516,7 @@ struct _virDomainParseTotalParam{
virCapsPtr caps;
virDomainXMLOptionPtr xmlopt;
void *parseOpaque;
+ virHashTablePtr bootHash;
unsigned int flags;
//internal parameters
@@ -19816,6 +19817,7 @@ virDomainDefParseXML(xmlDocPtr xml,
caps,
xmlopt,
parseOpaque,
+ NULL,
flags,
false,
false,
@@ -19861,7 +19863,11 @@ virDomainDefParseXML(xmlDocPtr xml,
if (!(def = virDomainDefNew()))
return NULL;
+ if (!(bootHash = virHashCreate(5, NULL)))
+ goto error;
+
param.def = def;
+ param.bootHash = bootHash;
while (parse_funs[fun_index]) {
if (parse_funs[fun_index](¶m) < 0)
--
2.8.3
7 years, 1 month
[libvirt] [RFC v2 REPOST] arm64: KVM: KVM API extensions for SVE
by Dave Martin
Hi all,
Reposting this to give people another chance to comment before I move
ahead...
---8<---
Here's a second, slightly more complete stab at the KVM API extensions
for SVE.
I haven't started implementing in earnest yet, so any comments at this
stage would be very helpful.
[libvir-list readers: this is a proposal for extending the KVM API on
AArch64 systems to support the Scalable Vector Extension [1], [2].
This has some interesting configuration and migration quirks -- see
"Vector length control" in particular, and feel free to throw questions
my way...]
Cheers
---Dave
[1] Overview
https://community.arm.com/processors/b/blog/posts/technology-update-the-s...
[2] Architecture spec
https://developer.arm.com/products/architecture/a-profile/docs/ddi0584/la...
---8<---
New feature KVM_ARM_VCPU_SVE:
* enables exposure of SVE to the guest
* enables visibility of / access to KVM_REG_ARM_SVE_*() via KVM reg
ioctls. The main purposes of this are a) is to allow userspace to hide
weird-sized registers that it doesn't understand how to deal with,
and b) allow SVE to be hidden from the VM so that it can migrate to
nodes that don't support SVE.
ZCR_EL1 is not specifically hidden, since it is "just a system register"
and does not have a weird size or semantics etc.
Registers:
* A new register size is defined KVM_REG_SIZE_U2048 (which can be
encoded sensibly using the next unused value for the reg size field
in the reg ID) (grep KVM_REG_SIZE_).
* Reg IDs for the SVE regs will be defined as "coproc" 0x14
(i.e., 0x14 << KVM_REG_ARM_COPROC_SHIFT)
KVM_REG_ARM_SVE_Z(n, i) is slice i of Zn (each slice is 2048 bits)
KVM_REG_ARM_SVE_P(n, i) is slice i of Pn (each slice is 256 bits)
KVM_REG_ARM_FFR(i) is slice i of FFR (each slice is 256 bits)
The slice sizes allow each register to be read/written in exactly
one slice for SVE.
Surplus bits (beyond the maximum VL supported by the vcpu) will
be read-as-zero write-ignore.
Reading/writing surplus slices will probably be forbidden, and the
surplus slices would not be reported via KVM_GET_REG_LIST.
(We could make these RAZ/WI too, but I'm not sure if it's worth it,
or why it would be useful.)
Future extensions to the architecture might grow the registers up
to 32 slices: this may or may not actually happen, but SVE keeps the
possibilty open. I've tried to design for it.
* KVM_REG_ARM_SVE_Z(n, 0) bits [127:0] alias Vn in
KVM_REG_ARM_CORE(fp_regs.v[n]) .. KVM_REG_ARM_CORE(fp_regs.v[n])+3.
It's simplest for userspace if the two views always appear to be
in sync, but it's unclear whether this is really useful. Perhaps
this can be relaxed if it's a big deal for the KVM implementation;
I don't know yet.
Vector length control:
Some means is needed to determine the set of vector lengths visible
to guest software running on a vcpu.
When a vcpu is created, the set would be defaulted to the maximal set
that can be supported while permitting each vcpu to run on any host
CPU. SVE has some virtualisation quirks which mean that this set may
exclude some vector lengths that are available for host userspace
applications. The common case should be that the sets are the same
however.
* New ioctl KVM_ARM_VCPU_{SET,GET}_SVE_VLS to set or retrieve the set of
vector lengths available to the guest.
Adding random vcpu ioctls
To configure a non-default set of vector lengths,
KVM_ARM_VCPU_SET_SVE_VLS can be called: this would only be permitted
before the vcpu is first run.
This is primarily intended for supporting migration, by providing a
robust check that the destination node will run the vcpu correctly.
In a cluster with non-uniform SVE implementation across nodes, this
also allows a specific set of VLs to be requested that the caller
knows is usable across the whole cluster.
For migration purposes, userspace would need to do
KVM_ARM_VCPU_GET_SVE_VLS at the origin node and store the returned
set as VM metadata: on the destination node,
KVM_ARM_VCPU_SET_SVE_VLS should be used to request that exact set of
VLs: if the destination node can't support that set of VLs, the call
will fail.
The interface would look something like:
ioctl(vcpu_fd, KVM_ARM_SVE_SET_VLS, __u64 vqs[SVE_VQ_MAX / 64]);
How to expose this to the user in an intelligible way would be a
problem for userspace to solve.
At present, other than initialising each vcpu to the maximum
supportable set of VLs, I don't propose having a way to probe for
what sets of VLs are supportable: the above call either succeeds or
fails.
Cheers
---Dave
_______________________________________________
kvmarm mailing list
kvmarm(a)lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
7 years, 1 month
[libvirt] [jenkins-ci PATCH 0/2] Fix virt-manager build failure
by Andrea Bolognani
By making a lot of compromises.
Not a perfect solution, but still better than not building
virt-manager at all until we've come up with a proper one
I reckon.
¯\_(ツ)_/¯
Andrea Bolognani (2):
guests: Install Python 3 dependencies for virt-manager
jobs: Switch all Python builds to Python 3
guests/host_vars/libvirt-centos-6/main.yml | 1 -
guests/host_vars/libvirt-centos-7/main.yml | 2 --
guests/host_vars/libvirt-debian-8/main.yml | 1 -
guests/host_vars/libvirt-ubuntu-14/main.yml | 1 -
guests/host_vars/libvirt-ubuntu-16/main.yml | 1 -
guests/vars/mappings.yml | 41 ++++++++++++++++-------------
guests/vars/projects/virt-manager.yml | 8 +++---
jobs/python-distutils.yaml | 8 +++---
projects/virt-manager.yaml | 2 +-
9 files changed, 31 insertions(+), 34 deletions(-)
--
2.14.3
7 years, 1 month
[libvirt] [jenkins-ci] lcitool: Use default python for creating salty passwords
by Martin Kletzander
On my system the crypt module in python2 doesn't have mksalt() function.
However python3 does and the code is perfectly fine python3 code as well. So
let's make it run in the default python version as that has the highest chance
to work.
Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com>
---
guests/lcitool | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/guests/lcitool b/guests/lcitool
index ccd0a597785a..24274d800742 100755
--- a/guests/lcitool
+++ b/guests/lcitool
@@ -18,7 +18,7 @@ die() {
hash_file() {
PASS_FILE="$1"
- python2 -c "
+ python -c "
import crypt
password = open('$PASS_FILE', 'r').read().strip()
print(crypt.crypt(password,
--
2.16.1
7 years, 1 month
[libvirt] [PATCH] util: Fix syntax-check
by Andrea Bolognani
Broken by 759b4d1b0fe5f4d84d98b99153dfa7ac289dd167.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
Pushed as a CI build fix.
src/util/virlog.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/util/virlog.c b/src/util/virlog.c
index 9105337ce..8f1e4800d 100644
--- a/src/util/virlog.c
+++ b/src/util/virlog.c
@@ -478,9 +478,8 @@ virLogHostnameString(char **rawmsg,
if (!virLogHostname)
return -1;
- if (virAsprintfQuiet(&hoststr, "hostname: %s", virLogHostname) < 0) {
+ if (virAsprintfQuiet(&hoststr, "hostname: %s", virLogHostname) < 0)
return -1;
- }
if (virLogFormatString(msg, 0, NULL, VIR_LOG_INFO, hoststr) < 0) {
VIR_FREE(hoststr);
--
2.14.3
7 years, 1 month
[libvirt] [PATCH] conf: Check for NUMA distances in validity check
by Michal Privoznik
NUMA distances are part of guest ABI (guests can read it
directly!) and therefore as such shouldn't change throughout the
lifetime of domain.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/conf/numa_conf.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/conf/numa_conf.c b/src/conf/numa_conf.c
index c906a53de..7d3f9e661 100644
--- a/src/conf/numa_conf.c
+++ b/src/conf/numa_conf.c
@@ -1073,7 +1073,7 @@ bool
virDomainNumaCheckABIStability(virDomainNumaPtr src,
virDomainNumaPtr tgt)
{
- size_t i;
+ size_t i, j;
if (virDomainNumaGetNodeCount(src) != virDomainNumaGetNodeCount(tgt)) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
@@ -1102,6 +1102,17 @@ virDomainNumaCheckABIStability(virDomainNumaPtr src,
"match source"), i);
return false;
}
+
+ for (j = 0; j < virDomainNumaGetNodeCount(src); j++) {
+ if (virDomainNumaGetNodeDistance(src, i, j) !=
+ virDomainNumaGetNodeDistance(tgt, i, j)) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("Target NUMA distance from %zu to %zu "
+ "doesn't match source"), i, j);
+
+ return false;
+ }
+ }
}
return true;
--
2.13.6
7 years, 1 month
[libvirt] [PATCH 0/4] qemu: Don't refresh 'halted' state for domain stats
by Peter Krempa
The halted state information is useless on most platforms and calling
'query-cpus' is very expensive. Don't report the info on platforms where
it does not make sense.
Peter Krempa (3):
qemu: driver: Extract vcpu halted state directly
qemu: Remove unused 'cpuhalted' argument from qemuDomainHelperGetVcpus
qemu: domain: Store vcpu halted state as a tristate
Viktor Mihajlovski (1):
qemu: Limit refresh of CPU halted state to s390
src/qemu/qemu_domain.c | 8 +++++++-
src/qemu/qemu_domain.h | 2 +-
src/qemu/qemu_driver.c | 36 +++++++++++++++---------------------
3 files changed, 23 insertions(+), 23 deletions(-)
--
2.15.0
7 years, 1 month
[libvirt] [PATCH RFCv2 0/4] Add optional pSeries features
by Andrea Bolognani
Applies on top of [req].
RFC because we still don't have a way of probing QEMU to figure
out whether the relevant toggles are available. Plus, there's no
documentation yet :)
Changes from [RFCv1]:
* don't nest features inside a <pseries/> element;
* implement all optional features.
[req] https://www.redhat.com/archives/libvir-list/2018-February/msg00298.html
[RFCv1] https://www.redhat.com/archives/libvir-list/2018-January/msg00779.html
Andrea Bolognani (4):
qemu: Implement the HTM pSeries feature
qemu: Implement the SBBC pSeries feature
qemu: Implement the CFPC pSeries feature
qemu: Implement the IBS pSeries feature
docs/schemas/domaincommon.rng | 30 ++++
src/conf/domain_conf.c | 74 +++++++++
src/conf/domain_conf.h | 15 ++
src/libvirt_private.syms | 2 +
src/qemu/qemu_capabilities.c | 17 +++
src/qemu/qemu_capabilities.h | 6 +
src/qemu/qemu_command.c | 165 +++++++++++++++++++++
src/qemu/qemu_domain.c | 22 +++
tests/qemuxml2argvdata/pseries-features-cfpc.args | 19 +++
tests/qemuxml2argvdata/pseries-features-cfpc.xml | 28 ++++
tests/qemuxml2argvdata/pseries-features-htm.args | 19 +++
tests/qemuxml2argvdata/pseries-features-htm.xml | 28 ++++
tests/qemuxml2argvdata/pseries-features-ibs.args | 19 +++
tests/qemuxml2argvdata/pseries-features-ibs.xml | 28 ++++
.../pseries-features-invalid-machine.xml | 1 +
tests/qemuxml2argvdata/pseries-features-sbbc.args | 19 +++
tests/qemuxml2argvdata/pseries-features-sbbc.xml | 28 ++++
tests/qemuxml2argvtest.c | 20 +++
tests/qemuxml2xmloutdata/pseries-features-cfpc.xml | 1 +
tests/qemuxml2xmloutdata/pseries-features-htm.xml | 1 +
tests/qemuxml2xmloutdata/pseries-features-ibs.xml | 1 +
tests/qemuxml2xmloutdata/pseries-features-sbbc.xml | 1 +
tests/qemuxml2xmltest.c | 12 ++
23 files changed, 556 insertions(+)
create mode 100644 tests/qemuxml2argvdata/pseries-features-cfpc.args
create mode 100644 tests/qemuxml2argvdata/pseries-features-cfpc.xml
create mode 100644 tests/qemuxml2argvdata/pseries-features-htm.args
create mode 100644 tests/qemuxml2argvdata/pseries-features-htm.xml
create mode 100644 tests/qemuxml2argvdata/pseries-features-ibs.args
create mode 100644 tests/qemuxml2argvdata/pseries-features-ibs.xml
create mode 100644 tests/qemuxml2argvdata/pseries-features-sbbc.args
create mode 100644 tests/qemuxml2argvdata/pseries-features-sbbc.xml
create mode 120000 tests/qemuxml2xmloutdata/pseries-features-cfpc.xml
create mode 120000 tests/qemuxml2xmloutdata/pseries-features-htm.xml
create mode 120000 tests/qemuxml2xmloutdata/pseries-features-ibs.xml
create mode 120000 tests/qemuxml2xmloutdata/pseries-features-sbbc.xml
--
2.14.3
7 years, 1 month
[libvirt] [PATCH v3 0/4] qemu: use arp table of host to get the
by Chen Hanxiao
introduce VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_ARP to get ip address
of VM from the output of /proc/net/arp
Chen Hanxiao (4):
util: introduce helper to parse /proc/net/arp
qemu: introduce qemuARPGetInterfaces to get IP from host's arp table
virsh: add --source arp to domifaddr
news: qemu: use arp table of host to get the IP address of guests
docs/news.xml | 9 ++++
include/libvirt/libvirt-domain.h | 1 +
po/POTFILES.in | 1 +
src/Makefile.am | 1 +
src/libvirt-domain.c | 7 +++
src/libvirt_private.syms | 5 ++
src/qemu/qemu_driver.c | 96 +++++++++++++++++++++++++++++++++
src/util/virarptable.c | 114 +++++++++++++++++++++++++++++++++++++++
src/util/virarptable.h | 48 +++++++++++++++++
tools/virsh-domain-monitor.c | 2 +
tools/virsh.pod | 7 +--
11 files changed, 288 insertions(+), 3 deletions(-)
create mode 100644 src/util/virarptable.c
create mode 100644 src/util/virarptable.h
--
2.14.3
7 years, 1 month
