Re: [Xen-devel] [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation

[Julien Grall <julien.grall@xxxxxxx>]

Hi Stefano,

On 05/24/2018 01:48 AM, Stefano Stabellini wrote:
> On Wed, 23 May 2018, Stefano Stabellini wrote:
> > On Tue, 22 May 2018, Julien Grall wrote:
> > > +
> > > +    default:
> > > +        ASSERT_UNREACHABLE();
> > > +        return false;
> > > +    }
> > > +
> > > +    switch ( ssbd_state )
> > > +    {
> > > +    case ARM_SSBD_FORCE_DISABLE:
> > > +    {
> > > +        static bool once = true;
> > > +
> > > +        if ( once )
> > > +            printk("%s disabled from command-line\n", entry->desc);
> > > +        once = false;
> > > +
> > > +        arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
> > > +        required = false;
> > > +
> > > +        break;
> > > +    }
> > > +
> > > +    case ARM_SSBD_RUNTIME:
> > > +        if ( required )
> > > +        {
> > > +            this_cpu(ssbd_callback_required) = 1;
> > We have the ARM_SSBD bit, the ssbd_state variable and
> > ssbd_callback_required. Both ARM_SSBD and ssbd_state are shared across
> > cores while ssbd_callback_required is per-cpu. Does
> > ssbd_callback_required really need to be per-cpu? Do we need both
> > variables? For instance, we could just return ssbd_state ==
> > ARM_SSBD_RUNTIME instead of this_cpu(ssbd_callback_required)?
> After reading the whole series, I think ssbd_state should be a per_cpu
> variable. parse_spec_ctrl initializes ssbd_state to the same value on
> all cpus. has_ssbd_mitigation modifies ssbd_state only on the CPUs it is
> running on. We get rid of ssbd_callback_required. The assembly fast past
> reads ssbd_state instead of ssbd_callback_required.
>
> What do you think?
We need to keep the global ssbd_state around for the vsmc code as we 
need to tell the guest what is the system-wide decision.
This is because a vCPU may move from a affected CPU to a non-affected 
one. So we need to inform the same on every vCPU (i.e mitigated, 
dynamic...).
Cheers,

--
Julien Grall

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