On Wed, Oct 11, 2017 at 19:42:36 +0200, Marc Hartmayer wrote:
On Wed, Oct 11, 2017 at 12:11 PM +0200, Jiri Denemark
<jdenemar(a)redhat.com> wrote:
> The new function is called qemuProcessRefreshCPU.
>
> Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
> ---
> src/qemu/qemu_process.c | 66 ++++++++++++++++++++++++++++++++-----------------
> 1 file changed, 43 insertions(+), 23 deletions(-)
>
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index 0cb023095b..5ed6b68eb8 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -6876,6 +6876,47 @@ qemuProcessRefreshDisks(virQEMUDriverPtr driver,
> }
>
>
> +static int
> +qemuProcessRefreshCPU(virQEMUDriverPtr driver,
> + virDomainObjPtr vm)
> +{
> + virCapsPtr caps = virQEMUDriverGetCapabilities(driver, false);
> + virCPUDefPtr host = NULL;
> + int ret = -1;
> +
> + if (!virQEMUCapsGuestIsNative(caps->host.arch, vm->def->os.arch) ||
> + !caps->host.cpu ||
> + !vm->def->cpu)
> + return 0;
> +
> + if (!caps)
> + goto cleanup;
That's somehow weird... We access 'caps->host.arch'/
'caps->host.cpu'
and after that we're checking for a null pointer?!
Oops, yes. Consider the following patch squashed in:
diff --git i/src/qemu/qemu_process.c w/src/qemu/qemu_process.c
index 5ed6b68eb8..8c33af28dd 100644
--- i/src/qemu/qemu_process.c
+++ w/src/qemu/qemu_process.c
@@ -6884,14 +6884,14 @@ qemuProcessRefreshCPU(virQEMUDriverPtr driver,
virCPUDefPtr host = NULL;
int ret = -1;
+ if (!caps)
+ return -1;
+
if (!virQEMUCapsGuestIsNative(caps->host.arch, vm->def->os.arch) ||
!caps->host.cpu ||
!vm->def->cpu)
return 0;
- if (!caps)
- goto cleanup;
-
/* If the domain with a host-model CPU was started by an old libvirt
* (< 2.3) which didn't replace the CPU with a custom one, let's do it
now
* since the rest of our code does not really expect a host-model CPU in a