public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: devel@edk2.groups.io, tphan@ventanamicro.com
Cc: michael.d.kinney@intel.com, gaoliming@byosoft.com.cn,
	zhiguang.liu@intel.com, kraxel@redhat.com,
	rahul1.kumar@intel.com, ray.ni@intel.com,
	sunilvl@ventanamicro.com, jiewen.yao@intel.com,
	andrei.warkentin@intel.com, ardb+tianocore@kernel.org
Subject: Re: [edk2-devel] [PATCH v2 2/3] UefiCpuPkg: RISC-V: MMU: Support Svpbmt extension
Date: Wed, 7 Feb 2024 19:15:17 +0100	[thread overview]
Message-ID: <a52884bf-3902-dec8-c1ce-5536db868fbf@redhat.com> (raw)
In-Reply-To: <20240207012910.2133-3-tphan@ventanamicro.com>

On 2/7/24 02:29, Tuan Phan wrote:
> The GCD EFI_MEMORY_UC and EFI_MEMORY_WC attributes will be
> supported when Svpbmt extension available.
> 
> Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
> ---
>  .../Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c | 25 ++++++++++++++++++-
>  .../BaseRiscVMmuLib/BaseRiscVMmuLib.inf       |  1 +
>  2 files changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> index 826a1d32a1d4..c50a28e97e4b 100644
> --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> @@ -36,6 +36,15 @@
>  #define PTE_PPN_SHIFT         10
>  #define RISCV_MMU_PAGE_SHIFT  12
>  
> +#define RISCV_CPU_FEATURE_PBMT_BITMASK  BIT2
> +#define PTE_PBMT_NC                     BIT61
> +#define PTE_PBMT_IO                     BIT62
> +#define PTE_PBMT_MASK                   (PTE_PBMT_NC | PTE_PBMT_IO)
> +
> +#define EFI_MEMORY_CACHETYPE_MASK  (EFI_MEMORY_UC | EFI_MEMORY_WC |  \
> +                                     EFI_MEMORY_WT | EFI_MEMORY_WB | \
> +                                     EFI_MEMORY_UCE)
> +

(1) I've stated this elsewhere -- introducing such a macro is justified,
but calling it EFI_* is not. The EFI_ prefix is reserved for the spec.

>  STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57, SATP_MODE_SV48, SATP_MODE_SV39, SATP_MODE_OFF };
>  STATIC UINTN  mMaxRootTableLevel;
>  STATIC UINTN  mBitPerLevel;
> @@ -514,6 +523,20 @@ GcdAttributeToPageAttribute (
>      RiscVAttributes &= ~RISCV_PG_X;
>    }
>  
> +  if ((PcdGet64 (PcdRiscVFeatureOverride) & RISCV_CPU_FEATURE_PBMT_BITMASK) != 0) {
> +    switch (GcdAttributes & EFI_MEMORY_CACHETYPE_MASK) {
> +      case EFI_MEMORY_UC:
> +        RiscVAttributes |= PTE_PBMT_IO;
> +        break;
> +      case EFI_MEMORY_WC:
> +        RiscVAttributes |= PTE_PBMT_NC;
> +        break;
> +      default:
> +        // Default PMA mode
> +        break;
> +    }
> +  }
> +
>    return RiscVAttributes;
>  }
>  

Several questions / observations:

(2) If the feature is cleared in the PCD, does it deserve a warning that
the attribute setting request cannot be honored?

(3) The memory cacheability attributes are expressed as distinct bits of
a bitmask because, for expressing *capabilities*, they must be possible
to OR together. However, when setting actual attributes, I think the
bitmask should contain *exactly* one bit set -- in other words, the
value of the bitmask should be an integral power of two (that's not hard
to check).

Do you agree about this? If so, I'd suggest rejecting the request (with
an appropriate status code) if zero bits, or multiple bits, are set.

  UINT64  CacheTypeMask;

  CacheType = GcdAttributes & MEMORY_CACHETYPE_MASK;
  if ((CacheType == 0) ||
      (((CacheType - 1) & CacheType) != 0)) {
    return EFI_INVALID_PARAMETER;
  }
  switch (CacheType) {
    ...
  }

This would of course require changing the GcdAttributeToPageAttribute()
prototype, because right now the function cannot return an error.


> @@ -559,7 +582,7 @@ RiscVSetMemoryAttributes (
>             BaseAddress,
>             Length,
>             PageAttributesSet,
> -           PTE_ATTRIBUTES_MASK,
> +           PTE_ATTRIBUTES_MASK | PTE_PBMT_MASK,
>             (UINTN *)RiscVGetRootTranslateTable (),
>             TRUE
>             );

(4) I feel we shouldn't try to clear PTE_PBMT_MASK if
PcdRiscVFeatureOverride tells us that Svpbmt is not available. Just a
thought.

> diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> index 51ebe1750e97..1dbaa81f3608 100644
> --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
> @@ -28,3 +28,4 @@
>  
>  [Pcd]
>    gUefiCpuPkgTokenSpaceGuid.PcdCpuRiscVMmuMaxSatpMode  ## CONSUMES
> +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride     ## CONSUMES

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115243): https://edk2.groups.io/g/devel/message/115243
Mute This Topic: https://groups.io/mt/104211195/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2024-02-07 18:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-07  1:29 [edk2-devel] [PATCH v2 0/3] RISC-V: Support Svpbmt extension Tuan Phan
2024-02-07  1:29 ` [edk2-devel] [PATCH v2 1/3] MdePkg.dec: RISC-V: Define override bit for " Tuan Phan
2024-02-07 18:01   ` Laszlo Ersek
2024-02-07  1:29 ` [edk2-devel] [PATCH v2 2/3] UefiCpuPkg: RISC-V: MMU: Support " Tuan Phan
2024-02-07 18:15   ` Laszlo Ersek [this message]
2024-02-28 18:00     ` Tuan Phan
2024-02-07  1:29 ` [edk2-devel] [PATCH v2 3/3] OvmfPkg/RiscVVirt: Override " Tuan Phan
2024-02-07 20:02   ` Laszlo Ersek
2024-02-07 20:08     ` Tuan Phan
2024-02-15  5:42 ` [edk2-devel] [PATCH v2 0/3] RISC-V: Support " Andrei Warkentin
2024-02-15  6:16   ` Tuan Phan
     [not found]   ` <17B3F4C51A165C5A.28807@groups.io>
2024-02-27  4:34     ` Tuan Phan
2024-02-28  4:42       ` Sunil V L
2024-02-28 17:22         ` Tuan Phan
2024-03-02  3:36       ` Andrei Warkentin

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-list 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=a52884bf-3902-dec8-c1ce-5536db868fbf@redhat.com \
    --to=devel@edk2.groups.io \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox