All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Julien Grall <julien@xen.org>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH 3/3] xen/arm: Add sb instruction support
Date: Wed, 4 May 2022 07:24:52 +0000	[thread overview]
Message-ID: <E67D129C-DCA4-479E-B8B8-4C7DF8CC92B9@arm.com> (raw)
In-Reply-To: <6571ead7-ff94-acb5-1e55-53ae69944bf0@xen.org>

Hi Julien,

> On 3 May 2022, at 19:47, Julien Grall <julien@xen.org> wrote:
> 
> Hi Bertrand,
> 
> On 03/05/2022 10:38, Bertrand Marquis wrote:
>> This patch is adding sb instruction support when it is supported by a
>> CPU on arm64.
>> To achieve this, the "sb" macro is moved to sub-arch macros.h so that we
>> can use sb instruction when available through alternative on arm64 and
>> keep the current behaviour on arm32.
> 
> SB is also supported on Arm32. So I would prefer to introduce the encoding right now and avoid duplicating the .macro sb.

I will look into that.

> 
>> 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 ?

> 
>> code for sb when the support is detected using isa64 coprocessor
> 
> s/coprocessor/system/

Ack

> 
>> register.
>> The sb instruction is encoded using its hexadecimal value.
> 
> This is necessary to avoid recursive macro, right?

This is necessary for several reasons:
- support compilers not supporting sb instructions (need encoding)
- handle the alternative code (we do not want to repeat this everywhere)
- avoid recursive macro

> 
>> diff --git a/xen/arch/arm/include/asm/arm64/macros.h b/xen/arch/arm/include/asm/arm64/macros.h
>> index 140e223b4c..e639cec400 100644
>> --- a/xen/arch/arm/include/asm/arm64/macros.h
>> +++ b/xen/arch/arm/include/asm/arm64/macros.h
>> @@ -1,6 +1,24 @@
>>  #ifndef __ASM_ARM_ARM64_MACROS_H
>>  #define __ASM_ARM_ARM64_MACROS_H
>>  +#include <asm/alternative.h>
>> +
>> +    /*
>> +     * Speculative barrier
>> +     */
>> +    .macro sb
>> +alternative_if_not ARM64_HAS_SB
>> +    dsb nsh
>> +    isb
>> +alternative_else
>> +/*
>> + * SB encoding as given in chapter C6.2.264 of ARM ARM (DDI 0487H.a).
>> + */
> 
> NIT: Please align the comment with ".inst" below. I also don't think it is necessary to mention the spec here. The instruction encoding is not going to change.
Ack

> 
>> +    .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.

> 
>> +alternative_endif
>> +    .endm
>> +
>>      /*
>>       * @dst: Result of get_cpu_info()
>>       */
>> diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
>> index 4719de47f3..9370805900 100644
>> --- a/xen/arch/arm/include/asm/cpufeature.h
>> +++ b/xen/arch/arm/include/asm/cpufeature.h
>> @@ -67,8 +67,9 @@
>>  #define ARM_WORKAROUND_BHB_LOOP_24 13
>>  #define ARM_WORKAROUND_BHB_LOOP_32 14
>>  #define ARM_WORKAROUND_BHB_SMCC_3 15
>> +#define ARM64_HAS_SB 16
>>  -#define ARM_NCAPS           16
>> +#define ARM_NCAPS           17
>>    #ifndef __ASSEMBLY__
>>  diff --git a/xen/arch/arm/include/asm/macros.h b/xen/arch/arm/include/asm/macros.h
>> index 1aa373760f..91ea3505e4 100644
>> --- a/xen/arch/arm/include/asm/macros.h
>> +++ b/xen/arch/arm/include/asm/macros.h
>> @@ -5,15 +5,6 @@
>>  # error "This file should only be included in assembly file"
>>  #endif
>>  -    /*
>> -     * Speculative barrier
>> -     * XXX: Add support for the 'sb' instruction
>> -     */
>> -    .macro sb
>> -    dsb nsh
>> -    isb
>> -    .endm
>> -
>>  #if defined (CONFIG_ARM_32)
>>  # include <asm/arm32/macros.h>
>>  #elif defined(CONFIG_ARM_64)
> 
> Cheers,

Thanks for the review

Cheers
Bertrand



  reply	other threads:[~2022-05-04  7:25 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-03  9:38 [PATCH 0/3] Spectre BHB follow up Bertrand Marquis
2022-05-03  9:38 ` [PATCH 1/3] xen/arm: Sync sysregs and cpuinfo with Linux 5.18-rc3 Bertrand Marquis
2022-05-03 18:08   ` Julien Grall
2022-05-04  7:39     ` Bertrand Marquis
2022-05-04  8:20       ` Julien Grall
2022-05-04  9:49         ` Bertrand Marquis
2022-05-04 11:49           ` Julien Grall
2022-05-10  2:03             ` Stefano Stabellini
2022-05-11 14:41               ` Bertrand Marquis
2022-05-11 15:20                 ` Julien Grall
2022-05-11 15:40                   ` Bertrand Marquis
2022-05-11 15:47                     ` Julien Grall
2022-05-11 16:01                       ` Bertrand Marquis
2022-05-11 16:25                         ` Julien Grall
2022-05-11 20:06                     ` Stefano Stabellini
2022-05-12 12:34                       ` Bertrand Marquis
2022-05-10  2:04   ` Stefano Stabellini
2022-05-11 14:41     ` Bertrand Marquis
2022-05-03  9:38 ` [PATCH 2/3] xen/arm: Advertise workaround 1 if we apply 3 Bertrand Marquis
2022-05-03 18:17   ` Julien Grall
2022-05-04  7:25     ` Bertrand Marquis
2022-05-05 10:51       ` Julien Grall
2022-05-03  9:38 ` [PATCH 3/3] xen/arm: Add sb instruction support Bertrand Marquis
2022-05-03 18:47   ` Julien Grall
2022-05-04  7:24     ` Bertrand Marquis [this message]
2022-05-04  8:06       ` Julien Grall
2022-05-05 15:17         ` Julien Grall
2022-05-09 10:08         ` Bertrand Marquis
2022-05-09 10:31           ` Julien Grall
2022-05-09 10:49             ` Bertrand Marquis
2022-05-09 11:08               ` Julien Grall
2022-05-09 11:40                 ` Bertrand Marquis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E67D129C-DCA4-479E-B8B8-4C7DF8CC92B9@arm.com \
    --to=bertrand.marquis@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.