[libvirt] [PATCH 1/4] qemu: Separate CPU updating code from qemuProcessReconnect

Jiri Denemark jdenemar at redhat.com
Thu Oct 12 07:18:36 UTC 2017


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 at redhat.com> wrote:
> > The new function is called qemuProcessRefreshCPU.
> >
> > Signed-off-by: Jiri Denemark <jdenemar at 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




More information about the libvir-list mailing list