From: Anshuman Khandual <anshuman.khandual@arm.com> To: Marc Zyngier <maz@kernel.org> Cc: 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, 29 Apr 2024 07:53:14 +0530 [thread overview] Message-ID: <ab6466f2-023e-4b5f-bb60-aadb9eee089a@arm.com> (raw) In-Reply-To: <871q73rufi.wl-maz@kernel.org> On 4/18/24 13:09, Marc Zyngier wrote: > + Fuad > > On Thu, 18 Apr 2024 06:38:03 +0100, > Anshuman Khandual <anshuman.khandual@arm.com> wrote: >> >> This replaces custom macros usage (i.e ID_AA64PFR0_EL1_ELx_64BIT_ONLY and >> ID_AA64PFR0_EL1_ELx_32BIT_64BIT) and instead directly uses register fields >> from ID_AA64PFR0_EL1 sysreg definition. >> >> Cc: Marc Zyngier <maz@kernel.org> >> Cc: Oliver Upton <oliver.upton@linux.dev> >> Cc: Catalin Marinas <catalin.marinas@arm.com> >> Cc: Will Deacon <will@kernel.org> >> Cc: linux-arm-kernel@lists.infradead.org >> Cc: kvmarm@lists.linux.dev >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> >> --- >> arch/arm64/kvm/hyp/include/nvhe/fixed_config.h | 8 ++++---- >> arch/arm64/kvm/hyp/nvhe/pkvm.c | 4 ++-- >> arch/arm64/kvm/hyp/nvhe/sys_regs.c | 2 +- >> 3 files changed, 7 insertions(+), 7 deletions(-) >> >> diff --git a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h >> index 51f043649146..0034bfffced6 100644 >> --- a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h >> +++ b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h >> @@ -52,10 +52,10 @@ >> * Supported by KVM >> */ >> #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. > > There is also a series from Fuad moving things around, and maybe > that's the opportunity to rework this while limiting the amount of > cosmetic churn. Not to that this fixed config stuff needs to be I guess that might be a better place to change the code instead. Because this series just replaces the derived register field from tools syreg, but will be happy to have those changes here as well in a separate pre/post patch. > reworked in order to match the runtime feature enforcement that the > rest of KVM has adopted. I am afraid, did not get the above. Could you please give some more details.
WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com> To: Marc Zyngier <maz@kernel.org> Cc: 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, 29 Apr 2024 07:53:14 +0530 [thread overview] Message-ID: <ab6466f2-023e-4b5f-bb60-aadb9eee089a@arm.com> (raw) In-Reply-To: <871q73rufi.wl-maz@kernel.org> On 4/18/24 13:09, Marc Zyngier wrote: > + Fuad > > On Thu, 18 Apr 2024 06:38:03 +0100, > Anshuman Khandual <anshuman.khandual@arm.com> wrote: >> >> This replaces custom macros usage (i.e ID_AA64PFR0_EL1_ELx_64BIT_ONLY and >> ID_AA64PFR0_EL1_ELx_32BIT_64BIT) and instead directly uses register fields >> from ID_AA64PFR0_EL1 sysreg definition. >> >> Cc: Marc Zyngier <maz@kernel.org> >> Cc: Oliver Upton <oliver.upton@linux.dev> >> Cc: Catalin Marinas <catalin.marinas@arm.com> >> Cc: Will Deacon <will@kernel.org> >> Cc: linux-arm-kernel@lists.infradead.org >> Cc: kvmarm@lists.linux.dev >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> >> --- >> arch/arm64/kvm/hyp/include/nvhe/fixed_config.h | 8 ++++---- >> arch/arm64/kvm/hyp/nvhe/pkvm.c | 4 ++-- >> arch/arm64/kvm/hyp/nvhe/sys_regs.c | 2 +- >> 3 files changed, 7 insertions(+), 7 deletions(-) >> >> diff --git a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h >> index 51f043649146..0034bfffced6 100644 >> --- a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h >> +++ b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h >> @@ -52,10 +52,10 @@ >> * Supported by KVM >> */ >> #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. > > There is also a series from Fuad moving things around, and maybe > that's the opportunity to rework this while limiting the amount of > cosmetic churn. Not to that this fixed config stuff needs to be I guess that might be a better place to change the code instead. Because this series just replaces the derived register field from tools syreg, but will be happy to have those changes here as well in a separate pre/post patch. > reworked in order to match the runtime feature enforcement that the > rest of KVM has adopted. I am afraid, did not get the above. Could you please give some more details. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-04-29 2:23 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 [this message] 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 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=ab6466f2-023e-4b5f-bb60-aadb9eee089a@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=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: linkBe 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.