All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>,
	linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	Oliver Upton <oliver.upton@linux.dev>,
	Will Deacon <will@kernel.org>,
	kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org,
	Fuad Tabba <tabba@google.com>
Subject: Re: [PATCH 1/2] KVM: arm64: Replace custom macros with fields from ID_AA64PFR0_EL1
Date: Mon, 13 May 2024 10:58:53 +0530	[thread overview]
Message-ID: <d571fb6c-a497-4710-bf10-0efb6a1d21fb@arm.com> (raw)
In-Reply-To: <Zj5i2x8Sh95YIfeq@J2N7QTR9R3>



On 5/10/24 23:39, Mark Rutland wrote:
> On Mon, Apr 29, 2024 at 07:53:14AM +0530, Anshuman Khandual wrote:
>> On 4/18/24 13:09, Marc Zyngier wrote:
>>> On Thu, 18 Apr 2024 06:38:03 +0100,
>>> Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>>>>  #define PVM_ID_AA64PFR0_RESTRICT_UNSIGNED (\
>>>> -	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL0), ID_AA64PFR0_EL1_ELx_64BIT_ONLY) | \
>>>> -	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL1), ID_AA64PFR0_EL1_ELx_64BIT_ONLY) | \
>>>> -	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL2), ID_AA64PFR0_EL1_ELx_64BIT_ONLY) | \
>>>> -	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL3), ID_AA64PFR0_EL1_ELx_64BIT_ONLY) | \
>>>> +	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL0), ID_AA64PFR0_EL1_EL0_IMP) | \
>>>> +	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL1), ID_AA64PFR0_EL1_EL1_IMP) | \
>>>> +	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL2), ID_AA64PFR0_EL1_EL2_IMP) | \
>>>> +	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL3), ID_AA64PFR0_EL1_EL3_IMP) | \
>>>
>>> If you are going to rework this, can we instead use something less
>>> verbose such as SYS_FIELD_GET()?
>>
>> Just wondering, is not FIELD_PREP() and SYS_FIELD_GET() does the exact opposite thing.
>> The earlier builds the entire register value from various constituents, where as the
>> later extracts a single register field from a complete register value instead. Or did
>> I just misunderstood something here.
>  
> He means use one of the SYS_FIELD_*() helpers, e.g. SYS_FIELD_PREP_ENUM(), with
> which this can be:
> 
> #define PVM_ID_AA64PFR0_RESTRICT_UNSIGNED (\
>         SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, EL0, IMP) | \
>         SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, EL1, IMP) | \
>         SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, EL2, IMP) | \
>         SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, EL3, IMP) | \
>         SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, RAS, IMP) \
>         )
> 
> ... which is far less verbose, and much easier to read.

Got it, this makes sense, will fold in the above changes and respin
after the merge window. Thanks for the clarification.

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>,
	linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	Oliver Upton <oliver.upton@linux.dev>,
	Will Deacon <will@kernel.org>,
	kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org,
	Fuad Tabba <tabba@google.com>
Subject: Re: [PATCH 1/2] KVM: arm64: Replace custom macros with fields from ID_AA64PFR0_EL1
Date: Mon, 13 May 2024 10:58:53 +0530	[thread overview]
Message-ID: <d571fb6c-a497-4710-bf10-0efb6a1d21fb@arm.com> (raw)
In-Reply-To: <Zj5i2x8Sh95YIfeq@J2N7QTR9R3>



On 5/10/24 23:39, Mark Rutland wrote:
> On Mon, Apr 29, 2024 at 07:53:14AM +0530, Anshuman Khandual wrote:
>> On 4/18/24 13:09, Marc Zyngier wrote:
>>> On Thu, 18 Apr 2024 06:38:03 +0100,
>>> Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>>>>  #define PVM_ID_AA64PFR0_RESTRICT_UNSIGNED (\
>>>> -	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL0), ID_AA64PFR0_EL1_ELx_64BIT_ONLY) | \
>>>> -	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL1), ID_AA64PFR0_EL1_ELx_64BIT_ONLY) | \
>>>> -	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL2), ID_AA64PFR0_EL1_ELx_64BIT_ONLY) | \
>>>> -	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL3), ID_AA64PFR0_EL1_ELx_64BIT_ONLY) | \
>>>> +	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL0), ID_AA64PFR0_EL1_EL0_IMP) | \
>>>> +	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL1), ID_AA64PFR0_EL1_EL1_IMP) | \
>>>> +	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL2), ID_AA64PFR0_EL1_EL2_IMP) | \
>>>> +	FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_EL3), ID_AA64PFR0_EL1_EL3_IMP) | \
>>>
>>> If you are going to rework this, can we instead use something less
>>> verbose such as SYS_FIELD_GET()?
>>
>> Just wondering, is not FIELD_PREP() and SYS_FIELD_GET() does the exact opposite thing.
>> The earlier builds the entire register value from various constituents, where as the
>> later extracts a single register field from a complete register value instead. Or did
>> I just misunderstood something here.
>  
> He means use one of the SYS_FIELD_*() helpers, e.g. SYS_FIELD_PREP_ENUM(), with
> which this can be:
> 
> #define PVM_ID_AA64PFR0_RESTRICT_UNSIGNED (\
>         SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, EL0, IMP) | \
>         SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, EL1, IMP) | \
>         SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, EL2, IMP) | \
>         SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, EL3, IMP) | \
>         SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, RAS, IMP) \
>         )
> 
> ... which is far less verbose, and much easier to read.

Got it, this makes sense, will fold in the above changes and respin
after the merge window. Thanks for the clarification.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-05-13  5:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-18  5:38 [PATCH 0/2] arm64: Drop ID_AA64PFR0_EL1_ELx_[64BIT_ONLY|32BIT_64BIT] Anshuman Khandual
2024-04-18  5:38 ` Anshuman Khandual
2024-04-18  5:38 ` [PATCH 1/2] KVM: arm64: Replace custom macros with fields from ID_AA64PFR0_EL1 Anshuman Khandual
2024-04-18  5:38   ` Anshuman Khandual
2024-04-18  7:39   ` Marc Zyngier
2024-04-18  7:39     ` Marc Zyngier
2024-04-29  2:23     ` Anshuman Khandual
2024-04-29  2:23       ` Anshuman Khandual
2024-05-10 18:09       ` Mark Rutland
2024-05-10 18:09         ` Mark Rutland
2024-05-13  5:28         ` Anshuman Khandual [this message]
2024-05-13  5:28           ` Anshuman Khandual
2024-04-18  5:38 ` [PATCH 2/2] arm64/cpufeature: " Anshuman Khandual
2024-04-18  5:38   ` Anshuman Khandual
2024-05-09  4:44 ` [PATCH 0/2] arm64: Drop ID_AA64PFR0_EL1_ELx_[64BIT_ONLY|32BIT_64BIT] Anshuman Khandual
2024-05-09  4:44   ` Anshuman Khandual

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=d571fb6c-a497-4710-bf10-0efb6a1d21fb@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=tabba@google.com \
    --cc=will@kernel.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.