On 09/05/2022 11:08, Bertrand Marquis wrote:
Hi Julien,
Hi,
On 4 May 2022, at 09:06, Julien Grall <[email protected]> wrote:
On 04/05/2022 08:24, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 3 May 2022, at 19:47, Julien Grall <[email protected]> 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.
If the need arise then we will check depending on that how we can support it
but in the current status as there is no use case I don’t think we need that.
It is not clear how I should read this answer... If you add SB in
cpuerrata.c, then a user will start to see message like:
"enabled workaround for Speculation Barrier".
Which is completely bogus. Replacing "dsb; isb" with "sb" is mostly an
optimization and none of the current use will end up to be
architecturaly executed.
I appreciate this is more work to add cpufeature.c. However, AFAIK,
there are no rush to get this optimization in (see why above) and muddy
(even temporarily) the logs.
Cheers,
--
Julien Grall
