Re: [PATCH 3/3] xen/arm: Add sb instruction support

[Julien Grall <julien@xxxxxxx>]

Hi,

On 04/05/2022 09:06, Julien Grall wrote:
> On 04/05/2022 08:24, Bertrand Marquis wrote:
> > Hi Julien,
> Hi Bertrand,
>
> > > On 3 May 2022, at 19:47, Julien Grall <julien@xxxxxxx> wrote:
> > > > A new cpuerrata capability is introduced to enable the alternative
> > > 'sb' is definitely not an erratum. Errata are for stuff that are 
> > > meant to be specific to one (or multiple) CPU and they are not part 
> > > of the architecture.
> > > This is the first time we introduce a feature in Xen. So we need to 
> > > add a new array in cpufeature.c that will cover 'SB' for now. In 
> > > future we could add feature like pointer auth, LSE atomics...
> > I am not quite sure why you would want to do that.
> >
> > Using the sb instruction is definitely something to do to solve 
> > erratas, if a CPU is not impacted by those erratas, why would you want 
> > to use this ?
> I agree that SB is used to solve errata but the instruction itself is 
> not a workaround (it may be part of it though). Instead, this is a more 
> efficient way to prevent speculation and will replace dsb/isb.
> Speculation is never going to disappear from processor. So, in the 
> future, there might be valid reason for us to say "We don't want the 
> processor to speculate". This would mean using SB.
> > > > +    .inst 0xd50330ff
> > > > +    nop
> > > Why do we need the NOP?
> > Alternative requires both sides to have the same size hence the nop to 
> > have 2 instructions as in the if.
> A few years ago we backported a patch from Linux to automatically add 
> nop. However, looking at the code, this would not handle this
Hmmm... Going through my e-mail again. I realized my sentence has not 
been finished. What I was meant to write that because the code is not 
handling it, then adding the extra nop is fine.
Cheers,

--
Julien Grall