On 08/19/2016 10:38 AM, Peter Krempa wrote:
> Add support for retrieving information regarding hotpluggable cpu units
> supported by qemu. Data returned by the command carries information
> needed to figure out the granularity of hotplug, the necessary cpu type
> name and the topology information.
>
> Note that qemu doesn't specify any particular order of the entries thus
> it's necessary sort them by socket_id, core_id and thread_id to the
> order libvirt expects.
> ---
>
> Notes:
> v2:
> - fixed alias string in comment
> - already ACKed
>
> src/qemu/qemu_monitor.h | 16 ++++
> src/qemu/qemu_monitor_json.c | 170 +++++++++++++++++++++++++++++++++++++++++++
> src/qemu/qemu_monitor_json.h | 5 ++
> 3 files changed, 191 insertions(+)
>
[...]
> +
> +/**
> + * [{
> + * "props": {
> + * "core-id": 0,
> + * "thread-id": 0,
> + * "socket-id": 0
> + * },
> + * "vcpus-count": 1,
> + * "qom-path": "/machine/unattached/device[0]",
> + * "type": "qemu64-x86_64-cpu"
> + * },
> + * {...}
> + * ]
> + */
> +static int
> +qemuMonitorJSONProcessHotpluggableCpusReply(virJSONValuePtr vcpu,
> + struct qemuMonitorQueryHotpluggableCpusEntry *entry)
> +{
> + virJSONValuePtr props;
> + const char *tmp;
> +
> + if (!(tmp = virJSONValueObjectGetString(vcpu, "type"))) {
> + virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> + _("query-hotpluggable-cpus didn't return device type"));
> + return -1;
> + }
> +
> + if (VIR_STRDUP(entry->type, tmp) < 0)
> + return -1;
> +
> + if (virJSONValueObjectGetNumberUint(vcpu, "vcpus-count", &entry->vcpus) < 0) {
> + virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> + _("query-hotpluggable-cpus didn't return vcpus-count"));
> + return -1;
> + }
> +
> + if (!(props = virJSONValueObjectGetObject(vcpu, "props"))) {
> + virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> + _("query-hotpluggable-cpus didn't return device props"));
> + return -1;
> + }
> +
> + entry->node_id = -1;
> + entry->socket_id = -1;
> + entry->core_id = -1;
> + entry->thread_id = -1;
> +
> + ignore_value(virJSONValueObjectGetNumberInt(props, "node-id", &entry->node_id));
> + ignore_value(virJSONValueObjectGetNumberInt(props, "socket-id", &entry->socket_id));
> + ignore_value(virJSONValueObjectGetNumberInt(props, "core-id", &entry->core_id));
> + ignore_value(virJSONValueObjectGetNumberInt(props, "thread-id", &entry->thread_id));
> +
> + if (entry->node_id == -1 && entry->socket_id == -1 &&
> + entry->core_id == -1 && entry->thread_id == -1) {
> + virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> + _("query-hotpluggable-cpus entry doesn't report "
> + "topology information"));
> + return -1;
> + }
> +
> + /* qom path is not present unless the vCPU is online */
> + if ((tmp = virJSONValueObjectGetString(vcpu, "qom-path"))) {
> + if (VIR_STRDUP(entry->qom_path, tmp) < 0)
> + return -1;
> +
> + /* alias is the part after last slash having a "vcpu" prefix */
> + if ((tmp = strrchr(tmp, '/')) && STRPREFIX(tmp + 1, "vcpu")) {
> + if (VIR_STRDUP(entry->alias, tmp + 1) < 0)
> + return -1;
Hmm... Just trying to understand... The example above has:
"qom-path": "/machine/unattached/device[0]",
So "/vcpuX" shows up when?
IOW: How does an entry look that has that vcpu string in it?
Ah - I see a couple patches later in the tests:
qom_path='/machine/peripheral/vcpu0'
I was also wondering why you extract this, but I see in later patches...
John
> + }
> + }
> +
> + return 0;
> +}
> +
> +
[...]
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list