Re: [PATCH v2 5/5] x86/xen: Fix xen_hvm_smp_init() when vector callback not available

[boris.ostrovsky@xxxxxxxxxx]

On 1/5/21 6:57 PM, David Woodhouse wrote:
> From: David Woodhouse <dwmw@xxxxxxxxxxxx>
>
> 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 <dwmw@xxxxxxxxxxxx>


Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>