On 1/5/21 6:57 PM, David Woodhouse wrote: > From: David Woodhouse <d...@amazon.co.uk> > > Only the IPI-related functions in the smp_ops should be conditional > on the vector callback being available. The rest should still happen: > > • xen_hvm_smp_prepare_boot_cpu() > > This function does two things, both of which should still happen if > there is no vector callback support. > > The call to xen_vcpu_setup() for vCPU0 should still happen as it just > sets up the vcpu_info for CPU0. That does happen for the secondary > vCPUs too, from xen_cpu_up_prepare_hvm(). > > The second thing it does is call xen_init_spinlocks(), which perhaps > counter-intuitively should *also* still be happening in the case > without vector callbacks, so that it can clear its local xen_pvspin > flag and disable the virt_spin_lock_key accordingly. > > Checking xen_have_vector_callback in xen_init_spinlocks() itself > would affect PV guests, so set the global nopvspin flag in > xen_hvm_smp_init() instead, when vector callbacks aren't available. > > • xen_hvm_smp_prepare_cpus() > > This does some IPI-related setup by calling xen_smp_intr_init() and > xen_init_lock_cpu(), which can be made conditional. And it sets the > xen_vcpu_id to XEN_VCPU_ID_INVALID for all possible CPUS, which does > need to happen. > > • xen_smp_cpus_done() > > This offlines any vCPUs which doesn't fit in the global shared_info > page, if separate vcpu_info placement isn't available. That part also > needs to happen regardless of vector callback support. > > • xen_hvm_cpu_die() > > This doesn't actually do anything other than commin_cpu_die() right > right now in the !vector_callback case; all three teardown functions > it calls should be no-ops. But to guard against future regressions > it's useful to call it anyway, and for it to explicitly check for > xen_have_vector_callback before calling those additional functions. > > Signed-off-by: David Woodhouse <d...@amazon.co.uk>
Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com>
