[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [PATCH 04/20] xen/domctl: Drop vcpu_alloc_lock



It is not entirely clear why this interlock was introduced in c/s 8cbb5278e
"x86/AMD: Add support for AMD's OSVW feature in guests".

At the time, svm_handle_osvw() could have seen an unexpected change in OSVW
(not the case now, due to the new CPUID Policy infrastructure), but even then,
it would have caused spurious changes in behaviour when handling
OSVW_{ID_LENGTH,STATUS} read requests on behalf of an already-running guest.

There are plenty of other aspects of domain creation which depend on hardware
details which may change across a microcode load, but where not protected by
this interlock.

A host administrator choosing to perform late microcode loading has plenty of
other problems to worry about, and is it not unreasonable to expect them to
temporarily cease domain construction activities while the microcode loading
is in progress.

Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
---
CC: Jan Beulich <JBeulich@xxxxxxxx>
---
 xen/arch/x86/platform_hypercall.c | 15 ---------------
 xen/common/domctl.c               | 18 ------------------
 xen/include/xen/domain.h          |  1 -
 3 files changed, 34 deletions(-)

diff --git a/xen/arch/x86/platform_hypercall.c 
b/xen/arch/x86/platform_hypercall.c
index ea18c32..b19f6ec 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -280,24 +280,9 @@ ret_t 
do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
 
         guest_from_compat_handle(data, op->u.microcode.data);
 
-        /*
-         * alloc_vcpu() will access data which is modified during
-         * microcode update
-         */
-        while ( !spin_trylock(&vcpu_alloc_lock) )
-        {
-            if ( hypercall_preempt_check() )
-            {
-                ret = hypercall_create_continuation(
-                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
-                goto out;
-            }
-        }
-
         ret = microcode_update(
                 guest_handle_to_param(data, const_void),
                 op->u.microcode.length);
-        spin_unlock(&vcpu_alloc_lock);
     }
     break;
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 9b7bc08..4d275ff 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -34,7 +34,6 @@
 #include <xsm/xsm.h>
 
 static DEFINE_SPINLOCK(domctl_lock);
-DEFINE_SPINLOCK(vcpu_alloc_lock);
 
 static int bitmap_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_bitmap,
                                    const unsigned long *bitmap,
@@ -567,20 +566,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
         /* Needed, for example, to ensure writable p.t. state is synced. */
         domain_pause(d);
 
-        /*
-         * Certain operations (e.g. CPU microcode updates) modify data which is
-         * used during VCPU allocation/initialization
-         */
-        while ( !spin_trylock(&vcpu_alloc_lock) )
-        {
-            if ( hypercall_preempt_check() )
-            {
-                ret =  hypercall_create_continuation(
-                    __HYPERVISOR_domctl, "h", u_domctl);
-                goto maxvcpu_out_novcpulock;
-            }
-        }
-
         /* We cannot reduce maximum VCPUs. */
         ret = -EINVAL;
         if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
@@ -630,9 +615,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
         ret = 0;
 
     maxvcpu_out:
-        spin_unlock(&vcpu_alloc_lock);
-
-    maxvcpu_out_novcpulock:
         domain_unpause(d);
         break;
     }
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 177cb35..1929fa0 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -82,7 +82,6 @@ void arch_dump_domain_info(struct domain *d);
 
 int arch_vcpu_reset(struct vcpu *);
 
-extern spinlock_t vcpu_alloc_lock;
 bool_t domctl_lock_acquire(void);
 void domctl_lock_release(void);
 
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.