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 1/3] xen/arm: Sync sysregs and cpuinfo with Linux 5.18-rc3
Date: Wed, 4 May 2022 07:39:38 +0000	[thread overview]
Message-ID: <2E66F8B4-4DDA-47E2-B93C-E36FEB70F552@arm.com> (raw)
In-Reply-To: <a05b426c-1800-a365-5b02-f82f0a391306@xen.org>

Hi Julien,

> On 3 May 2022, at 19:08, Julien Grall <julien@xen.org> wrote:
> 
> Hi Bertrand,
> 
> On 03/05/2022 10:38, Bertrand Marquis wrote:
>> Sync arm64 sysreg bit shift definitions with status of Linux kernel as
>> of 5.18-rc3 version (linux commit b2d229d4ddb1).
>> Sync ID registers sanitization with the status of Linux 5.18-rc3 and add
>> sanitization of ISAR2 registers.
> Please outline which specific commits you are actually backported. This would help to know what changed, why and also keep track of the autorships.
> 
> When possible, the changes should be separated to match each Linux commit we backport.

As those are exactly identical to the linux tree, one can easily use git blame on the linux source tree to find those information if it is needed.

I checked a bit and this is not something that was required before (for example when the cpufeature was introduced).

> 
>> Complete AA64ISAR2 and AA64MMFR1 with more fields.
>> While there add a comment for MMFR bitfields as for other registers in
>> the cpuinfo structure definition.
> 
> AFAICT, this patch is doing 3 different things that are somewhat related:
> - Sync cpufeature.c
> - Update the headers with unused defines
> - Complete the structure cpufeature.h
> 
> All those changes seem to be independent, so I think they should be done separately. This would help to keep the authorship right (your code vs Linux code).

This and the previous request to split using linux commit will actually end up in 10 patches or more.

In the current, the change can easily be checked doing a diff with the mentioned Linux version, so I am not really thrilled to make it more complex.

Please confirm that all this is really what you want.

> 
>> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
>> ---
>> xen/arch/arm/arm64/cpufeature.c | 18 +++++-
>> xen/arch/arm/include/asm/arm64/sysregs.h | 76 ++++++++++++++++++++----
>> xen/arch/arm/include/asm/cpufeature.h | 14 ++++-
>> 3 files changed, 91 insertions(+), 17 deletions(-)
>> diff --git a/xen/arch/arm/arm64/cpufeature.c b/xen/arch/arm/arm64/cpufeature.c
>> index 6e5d30dc7b..d9039d37b2 100644
>> --- a/xen/arch/arm/arm64/cpufeature.c
>> +++ b/xen/arch/arm/arm64/cpufeature.c
>> @@ -143,6 +143,16 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
>> 	ARM64_FTR_END,
>> };
>> +static const struct arm64_ftr_bits ftr_id_aa64isar2[] = {
>> +	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_HIGHER_SAFE, ID_AA64ISAR2_CLEARBHB_SHIFT, 4, 0),
>> +	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
>> +		 FTR_STRICT, FTR_EXACT, ID_AA64ISAR2_APA3_SHIFT, 4, 0),
>> +	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
> So we are using CONFIG_ARM64_PTR_AUTH. But this is not defined in Kconfig. I realize there are more in cpufeature.c (somehow I didn't spot during preview), but I don't think this is right to define CONFIG_* without an associated entry in Kconfig.
> 
> In one hand, I think it would be odd to add an entry in Kconfig because Xen wouldn't properly work if selected. On the other hand, it is useful if when we will implement pointer authentification.
> 
> So maybe we should just add the Kconfig entry with a comment explaning why they are not selected. Any thoughts?

This is really right and a very good catch.

I think it would make sense to introduce those in Kconfig in order to keep the code equivalent to Linux.

So I would suggest here to add hidden entries like this:

ARM64_PTR_AUTH
	def_bool n
	depends on ARM64
        help
          Pointer authentication support.
          This feature is not supported by Xen.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall



  reply	other threads:[~2022-05-04  7:40 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 [this message]
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
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=2E66F8B4-4DDA-47E2-B93C-E36FEB70F552@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.