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

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



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

 


Rackspace

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