[libvirt] [PATCH 0/3] Clean up qemuhotplugtest xml files
by Tomasz Flendrich
I plan on doing bigger changes to qemuhotplugtest.c. It's going
to test device attachment/detachment to both live (like now) and
persistent (something that is missing now) domains. More files
will be added, so I decided to clean up ones that are there now.
Many files were not even connected to any qemuxml2argv test,
and yet they were in tests/qemuxml2argvdata/
Tomasz Flendrich (3):
Move all qemuhotplugtest XMLs to one directory
Move domain and device xmls to different directories
Use virschematest on qemuhotplugtest domain xmls
tests/qemuhotplugtest.c | 52 ++++++-------
.../qemuhotplug-console-virtio.xml | 0
.../qemuhotplug-disk-cdrom-nochange.xml | 0
.../qemuhotplug-disk-scsi-2.xml | 0
.../qemuhotplug-disk-scsi.xml | 0
.../qemuhotplug-disk-usb.xml | 0
.../qemuhotplug-disk-virtio.xml | 0
...lug-graphics-spice-listen-network-password.xml} | 0
.../qemuhotplug-graphics-spice-listen.xml | 0
.../qemuhotplug-graphics-spice-nochange.xml | 0
...qemuhotplug-graphics-spice-timeout-nochange.xml | 0
...qemuhotplug-graphics-spice-timeout-password.xml | 0
.../qemuhotplug-qemu-agent-detach.xml | 0
.../qemuhotplug-qemu-agent.xml | 0
.../qemuhotplug-base+qemu-agent-detach.xml} | 0
.../qemuhotplug-base+qemu-agent.xml} | 0
.../qemuhotplug-base-live+disk-scsi.xml} | 0
.../qemuhotplug-base-live+disk-usb.xml} | 0
.../qemuhotplug-base-live+disk-virtio.xml} | 0
.../qemuhotplug-base-live+qemu-agent-detach.xml} | 0
.../qemuhotplug-base-live+qemu-agent.xml} | 0
.../qemuhotplug-base-live.xml} | 0
...base-with-scsi-controller-live+disk-scsi-2.xml} | 0
...qemuhotplug-base-with-scsi-controller-live.xml} | 0
...e-without-scsi-controller-live+disk-scsi-2.xml} | 0
...uhotplug-base-without-scsi-controller-live.xml} | 0
...otplug-console-compat-2-live+console-virtio.xml | 0
.../qemuhotplug-console-compat-2-live.xml} | 0
.../qemuhotplug-disk-cdrom.xml | 37 +++++++++
.../qemuhotplug-graphics-spice-listen-network.xml} | 0
.../qemuhotplug-graphics-spice-timeout.xml | 87 ++++++++++++++++++++++
.../qemuhotplug-graphics-spice.xml | 47 ++++++++++++
tests/virschematest.c | 3 +-
33 files changed, 199 insertions(+), 27 deletions(-)
rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-console-virtio.xml (100%)
rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-disk-cdrom-nochange.xml (100%)
rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-disk-scsi-2.xml (100%)
rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-disk-scsi.xml (100%)
rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-disk-usb.xml (100%)
rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-disk-virtio.xml (100%)
rename tests/{qemuhotplugtestdata/qemuhotplug-graphics-spice-listen-network.xml => qemuhotplugtestdevices/qemuhotplug-graphics-spice-listen-network-password.xml} (100%)
rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-graphics-spice-listen.xml (100%)
rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-graphics-spice-nochange.xml (100%)
rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-graphics-spice-timeout-nochange.xml (100%)
rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-graphics-spice-timeout-password.xml (100%)
rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-qemu-agent-detach.xml (100%)
rename tests/{qemuhotplugtestdata => qemuhotplugtestdevices}/qemuhotplug-qemu-agent.xml (100%)
rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-live+qemu-agent-detach.xml => qemuhotplugtestdomains/qemuhotplug-base+qemu-agent-detach.xml} (100%)
rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-live+qemu-agent.xml => qemuhotplugtestdomains/qemuhotplug-base+qemu-agent.xml} (100%)
rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-live+disk-scsi.xml => qemuhotplugtestdomains/qemuhotplug-base-live+disk-scsi.xml} (100%)
rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-live+disk-usb.xml => qemuhotplugtestdomains/qemuhotplug-base-live+disk-usb.xml} (100%)
rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-live+disk-virtio.xml => qemuhotplugtestdomains/qemuhotplug-base-live+disk-virtio.xml} (100%)
rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base+qemu-agent-detach.xml => qemuhotplugtestdomains/qemuhotplug-base-live+qemu-agent-detach.xml} (100%)
rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base+qemu-agent.xml => qemuhotplugtestdomains/qemuhotplug-base-live+qemu-agent.xml} (100%)
rename tests/{qemuxml2argvdata/qemuxml2argv-hotplug-base-live.xml => qemuhotplugtestdomains/qemuhotplug-base-live.xml} (100%)
rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-with-scsi-controller-live+disk-scsi-2.xml => qemuhotplugtestdomains/qemuhotplug-base-with-scsi-controller-live+disk-scsi-2.xml} (100%)
rename tests/{qemuxml2argvdata/qemuxml2argv-hotplug-base-with-scsi-controller-live.xml => qemuhotplugtestdomains/qemuhotplug-base-with-scsi-controller-live.xml} (100%)
rename tests/{qemuhotplugtestdata/qemuhotplug-hotplug-base-without-scsi-controller-live+disk-scsi-2.xml => qemuhotplugtestdomains/qemuhotplug-base-without-scsi-controller-live+disk-scsi-2.xml} (100%)
rename tests/{qemuxml2argvdata/qemuxml2argv-hotplug-base-without-scsi-controller-live.xml => qemuhotplugtestdomains/qemuhotplug-base-without-scsi-controller-live.xml} (100%)
rename tests/{qemuhotplugtestdata => qemuhotplugtestdomains}/qemuhotplug-console-compat-2-live+console-virtio.xml (100%)
rename tests/{qemuxml2argvdata/qemuxml2argv-console-compat-2-live.xml => qemuhotplugtestdomains/qemuhotplug-console-compat-2-live.xml} (100%)
create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-disk-cdrom.xml
rename tests/{qemuxml2argvdata/qemuxml2argv-graphics-spice-listen-network.xml => qemuhotplugtestdomains/qemuhotplug-graphics-spice-listen-network.xml} (100%)
create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-graphics-spice-timeout.xml
create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-graphics-spice.xml
--
2.7.4 (Apple Git-66)
8 years, 4 months
[libvirt] [PATCH 0/5] Couple of memleaks fixes
by Michal Privoznik
I've found these while procrastinating on friday afternoon.
Michal Privoznik (5):
virStorageEncryptionSecretFree: Don't leak secret lookup definition
qemuBuildCpuCommandLine: Don't leak @buf
qemuDomainObjPrivateFree: Free @masterKey too
qemuxml2argvtest: Don't leak dummy monitor
qemuxml2argvmock: Don't leak @netdef->ifname
src/qemu/qemu_command.c | 1 +
src/qemu/qemu_domain.c | 21 +++++++++++++++------
src/util/virstorageencryption.c | 1 +
tests/qemuxml2argvmock.c | 1 +
tests/qemuxml2argvtest.c | 5 +++--
5 files changed, 21 insertions(+), 8 deletions(-)
--
2.8.4
8 years, 4 months
[libvirt] [PATCH v3] virsh: allow both --uuid and --name at same time
by Chen Hanxiao
From: Chen Hanxiao <chenhanxiao(a)gmail.com>
#virsh list --uuid --name
49c765a0-25e7-40d0-964f-dac99724b32c c7
918f1dd6-b19f-412b-ba17-d113bad89af8 f23
Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com>
---
v3: add virsh.pod sections
v2: drop uuid-name option, enable both --uuid and --name
tools/virsh-domain-monitor.c | 14 ++++++++------
tools/virsh.pod | 10 ++++++++--
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/tools/virsh-domain-monitor.c b/tools/virsh-domain-monitor.c
index 0a93949..c712fa5 100644
--- a/tools/virsh-domain-monitor.c
+++ b/tools/virsh-domain-monitor.c
@@ -1844,12 +1844,8 @@ cmdList(vshControl *ctl, const vshCmd *cmd)
FILTER("state-shutoff", VIR_CONNECT_LIST_DOMAINS_SHUTOFF);
FILTER("state-other", VIR_CONNECT_LIST_DOMAINS_OTHER);
- if (optTable + optName + optUUID > 1) {
- vshError(ctl, "%s",
- _("Only one argument from --table, --name and --uuid "
- "may be specified."));
- return false;
- }
+ VSH_EXCLUSIVE_OPTIONS("table", "name");
+ VSH_EXCLUSIVE_OPTIONS("table", "uuid");
if (!optUUID && !optName)
optTable = true;
@@ -1907,6 +1903,12 @@ cmdList(vshControl *ctl, const vshCmd *cmd)
state == -2 ? _("saved")
: virshDomainStateToString(state));
}
+ } else if (optUUID && optName) {
+ if (virDomainGetUUIDString(dom, uuid) < 0) {
+ vshError(ctl, "%s", _("Failed to get domain's UUID"));
+ goto cleanup;
+ }
+ vshPrint(ctl, "%-36s %-30s\n", uuid, virDomainGetName(dom));
} else if (optUUID) {
if (virDomainGetUUIDString(dom, uuid) < 0) {
vshError(ctl, "%s", _("Failed to get domain's UUID"));
diff --git a/tools/virsh.pod b/tools/virsh.pod
index 601cb44..d7cd10e 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -524,8 +524,14 @@ Note that this flag does not filter the list of domains.
If I<--name> is specified, domain names are printed instead of the table
formatted one per line. If I<--uuid> is specified domain's UUID's are printed
instead of names. Flag I<--table> specifies that the legacy table-formatted
-output should be used. This is the default. All of these are mutually
-exclusive.
+output should be used. This is the default.
+
+If both I<--name> and I<--uuid> are specified, domain UUID's and names
+are printed side by side without any header. Flag I<--table> specifies
+that the legacy table-formatted output should be used. This is the
+default if neither I<--name> nor I<--uuid> are specified. Options
+I<--uuid> and I<--name> are mutually exclusive if option I<--table> is
+specified.
If I<--title> is specified, then the short domain description (title) is
printed in an extra column. This flag is usable only with the default
--
1.8.3.1
8 years, 4 months
[libvirt] [PATCH RFC 0/5] libxl: host cpu element in capabilities
by Joao Martins
Hey!
This series is the RFC I mentioned in cpu map discussion for libxl[0].
That is to implement host.cpu element in caps,by getting topology and xen
hwcaps parsing done, followed by having cpu-{compare,baseline} and get cpu
models APIs implemented. Last thing missing I think it would be to
libxl_cpuid_set the features to enable/disable whichever format we choose plus
the appropriate XML convertion to/from XM and XL config formats.
Cheers,
Joao
[0] https://www.redhat.com/archives/libvir-list/2016-July/msg00237.html
Joao Martins (5):
libxl: describe host topology in capabilities
libxl: describe host cpu features based on hwcaps
libxl: implement virConnectCompareCPU
libxl: implement virConnectBaselineCPU
libxl: implement virConnectGetCPUModelNames
src/libxl/libxl_capabilities.c | 148 ++++++++++++++++++++++++++++++++++++++---
src/libxl/libxl_driver.c | 74 +++++++++++++++++++++
2 files changed, 212 insertions(+), 10 deletions(-)
--
2.1.4
8 years, 4 months
[libvirt] [PATCH] libvirt.spec.in: soft-static allocation of qemu and kvm groups
by Jaroslav Suchanek
Follow the same logic for adding qemu user also for kvm and qemu groups. As
is described in https://fedoraproject.org/wiki/Packaging:UsersAndGroups
document there should be preallocated UIDs and GIDs for libvirt. A check for
required group id was added prior groupadd execution.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1351792
---
libvirt.spec.in | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 2b98836..3dc3193 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1464,8 +1464,20 @@ fi
# We want soft static allocation of well-known ids, as disk images
# are commonly shared across NFS mounts by id rather than name; see
# https://fedoraproject.org/wiki/Packaging:UsersAndGroups
-getent group kvm >/dev/null || groupadd -f -g 36 -r kvm
-getent group qemu >/dev/null || groupadd -f -g 107 -r qemu
+if ! getent group kvm >/dev/null; then
+ if ! getent group 36 >/dev/null; then
+ groupadd -f -g 36 -r kvm
+ else
+ groupadd -f -r kvm
+ fi
+fi
+if ! getent group qemu >/dev/null; then
+ if ! getent group 107 >/dev/null; then
+ groupadd -f -g 107 -r qemu
+ else
+ groupadd -f -r qemu
+ fi
+fi
if ! getent passwd qemu >/dev/null; then
if ! getent passwd 107 >/dev/null; then
useradd -r -u 107 -g qemu -G kvm -d / -s /sbin/nologin -c "qemu user" qemu
--
1.8.3.1
8 years, 4 months
Re: [libvirt] [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features
by David Hildenbrand
Are there any further comments, especially on patches 23-25, introducing new
QOM interfaces?
Also, if anybody is planning to look into this, please speak up :)
Otherwise it might make sense to put this onto the next KVM call agenda.
David
> This is our second attempt to implement CPU models for s390x. We realized
> that we also want to have features exposed via the CPU model. While doing
> that we realized that we want to have a better interface for libvirt.
>
> Unfortunately, CPU models on s390x are special and we have to take care of:
> - A CPU like z13 looks differently in various environments (under different
> LPAR versions, under different z/VM versions, under different KVM
> versions, export regulation) - we have _a lot_ of feature variability.
> - We still have certain features that are not published but might be
> implemented/introduced in the future. As they are a theoretical part
> of a CPU already, we have to find a way to model these future changes.
> - We still have certain features that are already published, but not
> implemented. Implementation might be added in the future in KVM.
> - We heavily rely on KVM to tell us which features it can actually
> virtualize - user space queries like "STFL(e)" give no guarantees.
> - Certain "subfeatures" were introduced in one run. In practice, they are
> always around, but in theory, subfeatures could be dropped in the future.
> - Just because two CPU models have the same features doesn't mean they
> are equal - some internal numbers might be different. E.g. we won't allow
> running a z13 under a zBC12 just by turning off features.
> - We cannot blindly enable all possible features for a CPU generation,
> the IBC "Instruction Blocking Control" in KVM will try to block
> instructions introduced with certain features. So a CPU generation always
> has some maximum feature set that is guaranteed to work.
>
> It all boils down to a specific released CPU to have.
> a) A fixed feature set that we expect it to be have on every hypervisor.
> b) A variable part that depends on the hypervisor and that could be
> extended in the future (adding not yet implemented features) that we
> always want to enable later on.
> c) A variable part that we want to enable only if requested - nested
> virtualization ("vsie") and assists are one example.
>
> But, the fixed feature set is not really what we want to use as a default.
> It is just like a really minimum, stable base.
>
> So we have
> a) A "stable" CPU model for each released CPU that will never change and
> maps to the minimum feature set we expect to be around on all
> hypervisors. e.g. "z13-base" or "z10EC.2-base". These are migration
> safe.
> b) A "default" CPU model for each released CPU, that can change between
> QEMU versions and that will always include the features we expect to
> be around in our currently supported environments and will contain only
> features we expect to be stable. E.g. nested virtualization will not be
> contained in these models. These models are not migration safe, e.g
> "z13" or "z10EC.2". The feature set can differ between QEMU versions.
> c) An internal "maximum" CPU model for each generation that tells us which
> features were supported as a maximum back when the hardware was
> released. This will not be exposed
>
> To not have to replicate all CPU model changes ("new default fetaures") in
> libvirt, to not duplicate the logic about compatibility and the like,
> our approach tries to keep all the QEMU logic in libvirt and provide
> standardized interfaces for libvirt to e.g. baseline, compare. This
> allows libvirt to not have to care about any model names or feature names,
> it can just pass the data from interface to interface and report it to
> the user.
>
> Also, libvirt might want to know what the "host" model looks like and
> convert a CPU model to a migration safe variant. For this reason, a QMP
> command is added that can create a migration safe variant of a variable
> CPU model, indicating only the delta changes done to a stable model.
>
> So we have:
> a) "query-cpu-model-expansion" - tell us what the "host" or a migration
> unsafe model looks like. Either falling back to a stable model or
> completely exposing all properties. We are interested in stable models.
> b) "query-cpu-model-comparison" - tell us how two CPU models compare,
> indicating which properties were responsible for the decision.
> c) "query-cpu-model-baseline" - create a new model out of two models,
> taking a requested level of stability into account.
>
> As we are aware that e.g. x86 has their own idea of a CPU model and their
> existing implementation in place, but are also looking into to ways to e.g.
> expand the "host" CPU model to a detailed representation, we designed the
> "expansion" interface to also allow that.
>
> Comments are very welcome, but please always keep the restrictions and
> specialties in mind when suggesting some major design changes.
>
> The header update will be replaced by a kvm-next header update as soon as
> the VSIE patches are upstream. The major KVM interface changes are already
> part of kvm-next.
>
> The current state is available on git://github.com/cohuck/qemu on branch
> "cpumodel-s390x".
>
> David Hildenbrand (26):
> s390x/cpumodel: "host" and "qemu" as CPU subclasses
> s390x/cpumodel: expose CPU class properties
> s390x/cpumodel: generate CPU feature group lists
> s390x/cpumodel: introduce CPU feature group definitions
> s390x/cpumodel: register defined CPU models as subclasses
> s390x/cpumodel: store the CPU model in the CPU instance
> s390x/cpumodel: expose features and feature groups as properties
> s390x/cpumodel: let the CPU model handle feature checks
> s390x/cpumodel: check and apply the CPU model
> s390x/sclp: factor out preparation of cpu entries
> s390x/sclp: introduce sclp feature blocks
> s390x/sclp: indicate sclp features
> s390x/sclp: propagate the ibc val(lowest and unblocked ibc)
> s390x/sclp: propagate the mha via sclp
> s390x/sclp: propagate hmfai
> update linux headers (CPU model)
> s390x/kvm: allow runtime-instrumentation for "none" machine
> s390x/kvm: implement CPU model support
> s390x/kvm: disable host model for existing compat machines
> s390x/kvm: let the CPU model control CMM(A)
> qmp: add QMP interface "query-cpu-model-expansion"
> qmp: add QMP interface "query-cpu-model-comparison"
> qmp: add QMP interface "query-cpu-model-baseline"
> s390x/cpumodel: implement QMP interface "query-cpu-model-expansion"
> s390x/cpumodel: implement QMP interface "query-cpu-model-comparison"
> s390x/cpumodel: implement QMP interface "query-cpu-model-baseline"
>
> Michael Mueller (2):
> s390x/cpumodel: introduce CPU features
> s390x/cpumodel: generate CPU feature lists for CPU models
>
> Makefile.target | 2 +-
> hw/s390x/s390-virtio-ccw.c | 5 +
> hw/s390x/s390-virtio.c | 6 +-
> hw/s390x/sclp.c | 35 +-
> include/hw/s390x/sclp.h | 17 +-
> include/sysemu/arch_init.h | 10 +
> linux-headers/asm-s390/kvm.h | 40 ++
> qapi-schema.json | 184 ++++++
> qmp-commands.hx | 18 +
> qmp.c | 22 +
> rules.mak | 1 +
> stubs/Makefile.objs | 3 +
> stubs/arch-query-cpu-model-baseline.c | 13 +
> stubs/arch-query-cpu-model-comparison.c | 12 +
> stubs/arch-query-cpu-model-expansion.c | 12 +
> target-s390x/Makefile.objs | 22 +-
> target-s390x/cpu-qom.h | 5 +
> target-s390x/cpu.c | 35 +-
> target-s390x/cpu.h | 5 +
> target-s390x/cpu_features.c | 376 +++++++++++
> target-s390x/cpu_features.h | 302 +++++++++
> target-s390x/cpu_models.c | 1055 +++++++++++++++++++++++++++++++
> target-s390x/cpu_models.h | 113 ++++
> target-s390x/gen-features.c | 587 +++++++++++++++++
> target-s390x/helper.c | 29 +-
> target-s390x/kvm.c | 346 +++++++++-
> target-s390x/machine.c | 14 +-
> 27 files changed, 3203 insertions(+), 66 deletions(-)
> create mode 100644 stubs/arch-query-cpu-model-baseline.c
> create mode 100644 stubs/arch-query-cpu-model-comparison.c
> create mode 100644 stubs/arch-query-cpu-model-expansion.c
> create mode 100644 target-s390x/cpu_features.c
> create mode 100644 target-s390x/cpu_features.h
> create mode 100644 target-s390x/cpu_models.c
> create mode 100644 target-s390x/cpu_models.h
> create mode 100644 target-s390x/gen-features.c
>
8 years, 4 months
[libvirt] [PATCH v2 0/4] devices: filesystem: type volume
by Olga Krishtal
The patches introduce new filesystem type volume:
<filesystem type='volume' accessmode='passthrough'>
<driver type='ploop' format='ploop'/>
<source pool='pool' volume='volume'/>
<target dir='/'/>
</filesystem>
This makes possible to use storage volumes as the source for disks.
v2:
-split patches
-rebased
Olga Krishtal (4):
filesystem: adds possibility to use storage pool as fs source
devices: filesystems: added volume type
vz: refactoring of prlsdkCreateCt
vz: support filesystem type volume
src/conf/domain_audit.c | 4 +-
src/conf/domain_conf.c | 52 +++++++++++++---
src/conf/domain_conf.h | 4 +-
src/libvirt_private.syms | 1 +
src/lxc/lxc_cgroup.c | 2 +-
src/lxc/lxc_container.c | 50 +++++++--------
src/lxc/lxc_controller.c | 18 +++---
src/lxc/lxc_native.c | 5 +-
src/lxc/lxc_process.c | 4 +-
src/openvz/openvz_conf.c | 6 +-
src/openvz/openvz_driver.c | 4 +-
src/qemu/qemu_command.c | 2 +-
src/storage/storage_driver.c | 4 +-
src/vbox/vbox_common.c | 6 +-
src/vmx/vmx.c | 6 +-
src/vz/vz_driver.c | 2 +-
src/vz/vz_sdk.c | 145 ++++++++++++++++++++++++++++++++++---------
src/vz/vz_sdk.h | 2 +-
18 files changed, 221 insertions(+), 96 deletions(-)
--
1.8.3.1
8 years, 4 months
[libvirt] [PATCH] Fix logic in qemuDomainObjPrivateXMLParseVcpu
by Daniel P. Berrange
The code in qemuDomainObjPrivateXMLParseVcpu for parsing
the 'idstr' string was comparing the overall boolean
result against 0 which was always true
qemu/qemu_domain.c: In function 'qemuDomainObjPrivateXMLParseVcpu':
qemu/qemu_domain.c:1482:59: error: comparison of constant '0' with boolean expression is always false [-Werror=bool-compare]
if ((idstr && virStrToLong_uip(idstr, NULL, 10, &idx)) < 0 ||
^
It was further performing two distinct error checks in
the same conditional and reporting a single error message,
which was misleading in one of the two cases.
This splits the conditional check into two parts with
distinct error messages and fixes the logic error.
Fixes the bug in
commit 5184f398b40a5e0d7d84b86182edcb2b48ab04ba
Author: Peter Krempa <pkrempa(a)redhat.com>
Date: Fri Jul 1 14:56:14 2016 +0200
qemu: Store vCPU thread ids in vcpu private data objects
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
Pushed as a broken build fix
src/qemu/qemu_domain.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index bf23d46..f7c659b 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -1479,10 +1479,15 @@ qemuDomainObjPrivateXMLParseVcpu(xmlNodePtr node,
idstr = virXMLPropString(node, "id");
- if ((idstr && virStrToLong_uip(idstr, NULL, 10, &idx)) < 0 ||
- !(vcpu = virDomainDefGetVcpu(def, idx))) {
+ if (idstr &&
+ (virStrToLong_uip(idstr, NULL, 10, &idx) < 0)) {
virReportError(VIR_ERR_INTERNAL_ERROR,
- _("invalid vcpu index '%s'"), idstr);
+ _("cannot parse vcpu index '%s'"), idstr);
+ goto cleanup;
+ }
+ if (!(vcpu = virDomainDefGetVcpu(def, idx))) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("invalid vcpu index '%u'"), idx);
goto cleanup;
}
--
2.7.4
8 years, 4 months
[libvirt] cpu_map data access for libxl driver
by Cedric Bosdonnat
Hi Jiri, all,
As I mentioned earlier today on IRC, I have started implementing CPU configuration
support for libxl driver.
libxl expects a string definition the state of all the feature (easy to create), but also
the numeric values for the CPU family and model. virCPUDef holds the name as a string, but
not the numeric values though there are stored in the cpu_map.xml.
For what libxl expects, search for 'cpuid=' in this man page:
http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html
Any idea how to get those values from the libxl driver?
--
Cedric
8 years, 4 months
