On Tue, 5 Feb 2019, Andrii Anisov wrote:
> On 05.02.19 00:06, Julien Grall wrote:
> > > A57+A53.
> > > 
> > > I see the following in my log:
> > > 
> > >      (XEN) alternatives: Patching with alt table 00000000002c6608 ->
> > > 00000000002c6c80
> > >      (XEN) CPU0 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> > >      (XEN) CPU2 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> > >      (XEN) CPU3 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> > >      (XEN) CPU1 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
> > 
> > Cortex-A53 should not be affected by spectre v2, so I imagine they are only
> > for A57?
> Yes, the log says the workaround is applied to the big cores only. As it
> should be.
> 
> > It is going to be hard to disable the workarounds by default. But we can
> > consider to provide host-wide or per-guest option to disable them on trusted
> > environment.
> We have to get numbers first than decide how to proceed.
> 
> > > > Also, when you mean possible, does it mean you haven't looked the
> > > > performance regression?
> > > We have a preliminary results about performance drop with xen4.12-unstable
> > > comparing to a our system with 4.10.
> > 
> > A lot of patches have not been backported in Xen 4.10 (including
> > Spectre/Meltdown) that will definitely fix hole but may have an impact on
> > the performance. There were not backported because of performance reason but
> > because of the complexity of the port and seemly lack of interest.
> I know that story. But customers are customers. And performance drop in the
> next SW version is always painful for them.
> So we need a good explanation (which Spectre mitigation might be), or better
> to show up no performance drop :).

I think it is acceptable to intruduce a "I know what I am doing, just
disable the fix" option. There might be cases where the user doesn't
care for Spectre mitigations. I see that Linux is going in this
direction of offering more disabling options too.