The host CPU definition from host capabilities may contain features
unknown to QEMU. Thus whenever we want to use this CPU definition, we
have to filter the unknown features.
https://bugzilla.redhat.com/show_bug.cgi?id=1495171
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
---
src/qemu/qemu_process.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 5ed6b68eb8..8553c5126f 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -6882,6 +6882,7 @@ qemuProcessRefreshCPU(virQEMUDriverPtr driver,
{
virCapsPtr caps = virQEMUDriverGetCapabilities(driver, false);
virCPUDefPtr host = NULL;
+ virCPUDefPtr cpu = NULL;
int ret = -1;
if (!virQEMUCapsGuestIsNative(caps->host.arch, vm->def->os.arch) ||
@@ -6901,7 +6902,13 @@ qemuProcessRefreshCPU(virQEMUDriverPtr driver,
if (!(host = virCPUCopyMigratable(caps->host.cpu->arch, caps->host.cpu)))
goto cleanup;
- if (virCPUUpdate(vm->def->os.arch, vm->def->cpu, host) < 0)
+ if (!(cpu = virCPUDefCopyWithoutModel(host)) ||
+ virCPUDefCopyModelFilter(cpu, host, false,
+ virQEMUCapsCPUFilterFeatures,
+ &caps->host.cpu->arch) < 0)
+ goto cleanup;
+
+ if (virCPUUpdate(vm->def->os.arch, vm->def->cpu, cpu) < 0)
goto cleanup;
if (qemuProcessUpdateCPU(driver, vm, QEMU_ASYNC_JOB_NONE) < 0)
@@ -6911,6 +6918,7 @@ qemuProcessRefreshCPU(virQEMUDriverPtr driver,
ret = 0;
cleanup:
+ virCPUDefFree(cpu);
virCPUDefFree(host);
virObjectUnref(caps);
return ret;
--
2.14.2
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Oct 11, 2017 at 12:11 PM +0200, Jiri Denemark <jdenemar@redhat.com> wrote:
> The host CPU definition from host capabilities may contain features
> unknown to QEMU. Thus whenever we want to use this CPU definition, we
> have to filter the unknown features.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1495171
>
> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
> ---
> src/qemu/qemu_process.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index 5ed6b68eb8..8553c5126f 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -6882,6 +6882,7 @@ qemuProcessRefreshCPU(virQEMUDriverPtr driver,
> {
> virCapsPtr caps = virQEMUDriverGetCapabilities(driver, false);
> virCPUDefPtr host = NULL;
> + virCPUDefPtr cpu = NULL;
> int ret = -1;
>
> if (!virQEMUCapsGuestIsNative(caps->host.arch, vm->def->os.arch) ||
> @@ -6901,7 +6902,13 @@ qemuProcessRefreshCPU(virQEMUDriverPtr driver,
> if (!(host = virCPUCopyMigratable(caps->host.cpu->arch, caps->host.cpu)))
> goto cleanup;
>
> - if (virCPUUpdate(vm->def->os.arch, vm->def->cpu, host) < 0)
Maybe you could add a comment about what we're doing here... (and
why). Since it wasn't that clear that it's needed here.
> + if (!(cpu = virCPUDefCopyWithoutModel(host)) ||
> + virCPUDefCopyModelFilter(cpu, host, false,
> + virQEMUCapsCPUFilterFeatures,
> + &caps->host.cpu->arch) < 0)
> + goto cleanup;
> +
> + if (virCPUUpdate(vm->def->os.arch, vm->def->cpu, cpu) < 0)
> goto cleanup;
>
> if (qemuProcessUpdateCPU(driver, vm, QEMU_ASYNC_JOB_NONE) < 0)
> @@ -6911,6 +6918,7 @@ qemuProcessRefreshCPU(virQEMUDriverPtr driver,
> ret = 0;
>
> cleanup:
> + virCPUDefFree(cpu);
> virCPUDefFree(host);
> virObjectUnref(caps);
> return ret;
> --
> 2.14.2
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
--
Beste Grüße / Kind regards
Marc Hartmayer
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Oct 11, 2017 at 12:11:16PM +0200, Jiri Denemark wrote: > The host CPU definition from host capabilities may contain features > unknown to QEMU. Thus whenever we want to use this CPU definition, we > have to filter the unknown features. Might be nice to explicitly mention in the commit message that this fixes the issue while reconnecting to QEMU process started by old libvirt that keeps "host-model" in the status XML. Took me some time to figure that out :). > https://bugzilla.redhat.com/show_bug.cgi?id=1495171 > > Signed-off-by: Jiri Denemark <jdenemar@redhat.com> > --- > src/qemu/qemu_process.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) Reviewed-by: Pavel Hrdina <phrdina@redhat.com> -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Oct 17, 2017 at 12:57:10 +0200, Pavel Hrdina wrote: > On Wed, Oct 11, 2017 at 12:11:16PM +0200, Jiri Denemark wrote: > > The host CPU definition from host capabilities may contain features > > unknown to QEMU. Thus whenever we want to use this CPU definition, we > > have to filter the unknown features. > > Might be nice to explicitly mention in the commit message that this > fixes the issue while reconnecting to QEMU process started by old > libvirt that keeps "host-model" in the status XML. Took me some time > to figure that out :). Yeah, sorry about it. What about the following commit message? When reconnecting to a domain started with a host-model CPU which was started by old libvirt that did not replace host-model with the real CPU definition, libvirt replaces the host-model CPU with the CPU from capabilities (because this is what the old libvirt did when it started the domain). Without this patch libvirt could use features unknown to QEMU in the CPU definition which replaced the original host-model CPU. Such domain would keep running just fine, but any attempt to migrate it will fail and once the domain is saved or snapshotted, restoring it would fail too. In other words whenever we want to use this CPU definition, we have to filter the unknown features. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Oct 17, 2017 at 01:15:43PM +0200, Jiri Denemark wrote: > On Tue, Oct 17, 2017 at 12:57:10 +0200, Pavel Hrdina wrote: > > On Wed, Oct 11, 2017 at 12:11:16PM +0200, Jiri Denemark wrote: > > > The host CPU definition from host capabilities may contain features > > > unknown to QEMU. Thus whenever we want to use this CPU definition, we > > > have to filter the unknown features. > > > > Might be nice to explicitly mention in the commit message that this > > fixes the issue while reconnecting to QEMU process started by old > > libvirt that keeps "host-model" in the status XML. Took me some time > > to figure that out :). > > Yeah, sorry about it. What about the following commit message? > > When reconnecting to a domain started with a host-model CPU which was > started by old libvirt that did not replace host-model with the real CPU > definition, libvirt replaces the host-model CPU with the CPU from > capabilities (because this is what the old libvirt did when it started > the domain). Without this patch libvirt could use features unknown to > QEMU in the CPU definition which replaced the original host-model CPU. > Such domain would keep running just fine, but any attempt to migrate it > will fail and once the domain is saved or snapshotted, restoring it > would fail too. > > In other words whenever we want to use this CPU definition, we have to > filter the unknown features. Reviewed-by: Pavel Hrdina <phrdina@redhat.com> -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2025 Red Hat, Inc.