If we cannot allocate the XIVE VPs in OPAL, the creation of a XIVE or
XICS-on-XIVE device is aborted as expected, but we leave kvm->arch.xive
set forever since the release method isn't called in this case. Any
subsequent tentative to create a XIVE or XICS-on-XIVE for this VM will
thus always fail (DoS). This is a problem for QEMU since it destroys
and re-creates these devices when the VM is reset: the VM would be
restricted to using the much slower emulated XIVE or XICS forever.
As an alternative to adding rollback, do not assign kvm->arch.xive before
making sure the XIVE VPs are allocated in OPAL.
Cc: stable@vger.kernel.org # v5.2
Fixes: 5422e95103cf ("KVM: PPC: Book3S HV: XIVE: Replace the 'destroy' method by a 'release' method")
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
 
        pr_devel("Creating xive for partition\n");
 
+       /* Already there ? */
+       if (kvm->arch.xive)
+               return -EEXIST;
+
        xive = kvmppc_xive_get_device(kvm, type);
        if (!xive)
                return -ENOMEM;
        xive->kvm = kvm;
        mutex_init(&xive->lock);
 
-       /* Already there ? */
-       if (kvm->arch.xive)
-               ret = -EEXIST;
-       else
-               kvm->arch.xive = xive;
-
        /* We use the default queue size set by the host */
        xive->q_order = xive_native_default_eq_shift();
        if (xive->q_order < PAGE_SHIFT)
        if (ret)
                return ret;
 
+       kvm->arch.xive = xive;
        return 0;
 }
 
 
        dev->private = xive;
        xive->dev = dev;
        xive->kvm = kvm;
-       kvm->arch.xive = xive;
        mutex_init(&xive->mapping_lock);
        mutex_init(&xive->lock);
 
        if (ret)
                return ret;
 
+       kvm->arch.xive = xive;
        return 0;
 }