On 01/30/2015 08:21 AM, Peter Krempa wrote:
> When using 'acpi-dimm' memory devices with qemu, some of the information
> like the slot number and base address need to be reloaded from qemu
> after process start so that it reflects the actual state. The state then
> allows to use memory devices across migrations.
> ---
> src/qemu/qemu_domain.c | 43 ++++++++++++++++
> src/qemu/qemu_domain.h | 4 ++
> src/qemu/qemu_monitor.c | 45 +++++++++++++++++
> src/qemu/qemu_monitor.h | 14 ++++++
> src/qemu/qemu_monitor_json.c | 116 +++++++++++++++++++++++++++++++++++++++++++
> src/qemu/qemu_monitor_json.h | 5 ++
> src/qemu/qemu_process.c | 4 ++
> 7 files changed, 231 insertions(+)
>
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 25540c4..df912a6 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -2773,6 +2773,49 @@ qemuDomainUpdateDeviceList(virQEMUDriverPtr driver,
> return 0;
> }
>
> +
> +int
> +qemuDomainUpdateMemoryDeviceInfo(virQEMUDriverPtr driver,
> + virDomainObjPtr vm,
> + int asyncJob)
> +{
> + qemuDomainObjPrivatePtr priv = vm->privateData;
> + virHashTablePtr meminfo = NULL;
> + size_t i;
> +
> + if (vm->def->nmems == 0)
> + return 0;
> +
> + if (qemuDomainObjEnterMonitorAsync(driver, vm, asyncJob) < 0)
> + return -1;
> + if (qemuMonitorGetMemoryDeviceInfo(priv->mon, &meminfo) < 0) {
> + ignore_value(qemuDomainObjExitMonitor(driver, vm));
> + return -1;
> + }
> +
> + if (qemuDomainObjExitMonitor(driver, vm) < 0)
This would leak meminfo
> + return -1;
> +
I know we don't have a "norm" for how this sequence goes, but along with
Jan's point about -2 being checked back in the caller... The "norm"
seems to be to:
ret = qemuMonitor*();
if (*ExitMonitor) < 0)
ret = -1;
goto cleanup or error;
if (ret < 0)
goto cleanup;
...
Caller would probably want to make sure the VM is still active or not.
> + for (i = 0; i < vm->def->nmems; i++) {
> + virDomainMemoryDefPtr mem = vm->def->mems[i];
> + qemuMonitorMemoryDeviceInfoPtr dimm;
> +
> + if (!mem->info.alias)
> + continue;
> +
> + if (!(dimm = virHashLookup(meminfo, mem->info.alias)))
> + continue;
> +
> + mem->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_ACPI_DIMM;
> + mem->info.addr.acpiDimm.slot = dimm->slot;
> + mem->info.addr.acpiDimm.base = dimm->address;
> + }
> +
cleanup:
> + virHashFree(meminfo);
> + return ret;
> +}
> +
> +
> bool
> qemuDomainDefCheckABIStability(virQEMUDriverPtr driver,
> virDomainDefPtr src,
<...snip...>
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index b0f7b1c..ba7c8e2 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -4871,6 +4871,10 @@ int qemuProcessStart(virConnectPtr conn,
> if (qemuDomainUpdateDeviceList(driver, vm, asyncJob) < 0)
> goto cleanup;
>
> + VIR_DEBUG("Updating info of memory devices");
> + if (qemuDomainUpdateMemoryDeviceInfo(driver, vm, asyncJob) < 0)
> + goto cleanup;
> +
Haven't looked forward yet, but is this something that needs to be done
at qemuProcessReconnec ?
John
> /* Technically, qemuProcessStart can be called from inside
> * QEMU_ASYNC_JOB_MIGRATION_IN, but we are okay treating this like
> * a sync job since no other job can call into the domain until
>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list