ISA string discovery for FW

[Dhaval Sharma]

Hi,

While working on CMO support, I realized that there is an obvious requirement to detect whether CMO ext are supported or not. For OS we have defined RHCT like arch spec to acquire such an ISA string. RHCT is populated by platform FW. There is no arch way for EDK2 like platform FW to discover this string other than acquiring it from DT.

Would it help to have an arch way for non m-mode stages to discover ISA string (which could be through SBI extn?). This change should help with s-mode UEFI implementations which is our primary config.

=D

[Sunil V L]

Hi Dhaval,

What is the issue with getting ISA string from DT?

[Dhaval Sharma]

Hi Sunil,

My point is that reading ISA strings is going to be important for different stages of FW on RiscV. If we look at FW stages as independent/decoupled from each other, primarily m-mode and s-mode, in my opinion it will be a good idea to have an arch way of identifying ISA string-like information. DT is not something we are considering part of BRS i.e. Other arch like X86 have CPUID like instructions which would work at various points in FW. I am not sure about ARM though.

If we consider a scenario where single m-mode FW being used for different configurations of systems which have different s-mode FW (u-boot/edk2), such a standard way (defined in BRS?) of discovering extension would be more scalable.

Just a thought, and I know we want to be careful about adding more extensions but wanted to share a thought and see what others think about this.

On a side note:

For extn like CMO where a higher priv decides if lower priv has access to the feature or not, what happens in the scenario for some reason i.e. m-mode decides NOT to enable a particular feature? Do we edit the ISA string and send it to the next stage? P.S. current implementation in Linux (and where we are trending) we assume features available == features enabled (if it is there in the string assume it is enabled too).

=D

--

Thanks!

=D

[Atish Kumar Patra]

On Thu, Jul 27, 2023 at 9:36 PM Dhaval Sharma <dha...@rivosinc.com> wrote:
>
> Hi Sunil,
> My point is that reading ISA strings is going to be important for different stages of FW on RiscV. If we look at FW stages as independent/decoupled from each other, primarily m-mode and s-mode, in my opinion it will be a good idea to have an arch way of identifying ISA string-like information. DT is not something we are considering part of BRS i.e. Other arch like X86 have CPUID like instructions which would work at various points in FW. I am not sure about ARM though.

AFAIK, ARM also uses DT to pass between various stages.

> If we consider a scenario where single m-mode FW being used for different configurations of systems which have different s-mode FW (u-boot/edk2), such a standard way (defined in BRS?) of discovering extension would be more scalable.
>

I am assuming you are talking about the firmware stage which creates
ACPI tables and looking for a standard way to discover the ISA
extension details to put it in the RHCT table.
You can always use DT for that.

> Just a thought, and I know we want to be careful about adding more extensions but wanted to share a thought and see what others think about this.
>
> On a side note:
> For extn like CMO where a higher priv decides if lower priv has access to the feature or not, what happens in the scenario for some reason i.e. m-mode decides NOT to enable a particular feature? Do we edit the ISA string and send it to the next stage? P.S. current implementation in Linux (and where we are trending) we assume features available == features enabled (if it is there in the string assume it is enabled too).

Yes. It's M-mode firmware's responsibility to patch the DT or handle
the traps on behalf of S-mode if it doesn't want to expose that
particular ISA extension to lower privilege mode.
The patching DT would be obviously the easy choice. The DT/firmware
comes from vendors. They need to make sure that both of them align. A
later booting stage can always pass a different version DT to Linux
and will fail if it doesn't describe correctly.

>
> =D
>
> On Thu, Jul 27, 2023 at 10:09 AM Sunil V L <sun...@ventanamicro.com> wrote:
>>
>> Hi Dhaval,
>>
>> What is the issue with getting ISA string from DT?
>>
>> On 26/07/23 22:46, Dhaval Sharma wrote:
>> > Hi,
>> > While working on CMO support, I realized that there is an obvious
>> > requirement to detect whether CMO ext are supported or not. For OS we
>> > have defined RHCT like arch spec to acquire such an ISA string. RHCT
>> > is populated by platform FW. There is no arch way for EDK2 like
>> > platform FW to discover this string other than acquiring it from DT.
>> >
>> > Would it help to have an arch way for non m-mode stages to discover
>> > ISA string (which could be through SBI extn?). This change should help
>> > with s-mode UEFI implementations which is our primary config.
>> >
>> > =D
>
>
>
> --
> Thanks!
> =D
>

> --
> You received this message because you are subscribed to the Google Groups "RISC-V Firmware Exchange" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fw-exchange...@riscv.org.
> To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/CAAxYnhTac8deMuik69JVk1s6v6bMA_4hKEC2J__WhO%2BZL9pj4g%40mail.gmail.com.

[Dhaval Sharma]

To clarify this further there are two aspects:

1. A need to have a specification for various ways of ISA string discovery in FW. For now I am focused on this point.
2. How that discovery happens could be a combination of DT, SBI extension (or even HOB in case of UEFI). This point is mute if we do not think #1 is required.

So first I wanted to discuss if adding some sort of standardization helps. That would mean, we add details on how ISA discovery happens as part of BRS. My point was that such clarity will help different FW developers given that ISA string discovery is quite fundamental to the boot flow.

Take a look at this patch where we are planning to define EFI_HOB_TYPE_CPU_RISCV. Would it not be better to add an ISA string as part of this HOB? To me it sounds more natural to have it there instead of parsing it from DT when PI is passing this information to Dxe. While in OpenSBI as you mentioned below DT might make more sense.

I am just documenting my thoughts here and if required we could add broader audience (through PRS or BRS forums) but wanted to see if there are more thoughts from FW team in this line.

=D

--

Thanks!

=D

[Sunil V L]

Hi Dhaval,

On 31/07/23 10:08, Dhaval Sharma wrote:

To clarify this further there are two aspects:

1. A need to have a specification for various ways of ISA string discovery in FW. For now I am focused on this point.
2. How that discovery happens could be a combination of DT, SBI extension (or even HOB in case of UEFI). This point is mute if we do not think #1 is required.

So first I wanted to discuss if adding some sort of standardization helps. That would mean, we add details on how ISA discovery happens as part of BRS. My point was that such clarity will help different FW developers given that ISA string discovery is quite fundamental to the boot flow.

Take a look at this patch where we are planning to define EFI_HOB_TYPE_CPU_RISCV. Would it not be better to add an ISA string as part of this HOB? To me it sounds more natural to have it there instead of parsing it from DT when PI is passing this information to Dxe. While in OpenSBI as you mentioned below DT might make more sense.

Unless I am missing something, creating a HOB for FDT and pass to next phase is a standard across architectures and it is required anyway to install FDT pointer UEFI configuration table for DT based systems. Why should we define new thing for ISA alone when we can pass entire FDT?

Thanks,

Sunil

[Tuan Phan]

Hi Sunil,

On Mon, Jul 31, 2023 at 4:46 AM Sunil V L <sun...@ventanamicro.com> wrote:

Hi Dhaval,

On 31/07/23 10:08, Dhaval Sharma wrote:

To clarify this further there are two aspects:

1. A need to have a specification for various ways of ISA string discovery in FW. For now I am focused on this point.
2. How that discovery happens could be a combination of DT, SBI extension (or even HOB in case of UEFI). This point is mute if we do not think #1 is required.

So first I wanted to discuss if adding some sort of standardization helps. That would mean, we add details on how ISA discovery happens as part of BRS. My point was that such clarity will help different FW developers given that ISA string discovery is quite fundamental to the boot flow.

Take a look at this patch where we are planning to define EFI_HOB_TYPE_CPU_RISCV. Would it not be better to add an ISA string as part of this HOB? To me it sounds more natural to have it there instead of parsing it from DT when PI is passing this information to Dxe. While in OpenSBI as you mentioned below DT might make more sense.

Unless I am missing something, creating a HOB for FDT and pass to next phase is a standard across architectures and it is required anyway to install FDT pointer UEFI configuration table for DT based systems. Why should we define new thing for ISA alone when we can pass entire FDT?

=> If the info that is standard then it is better to export in HOB so any modules/drivers just provide GUID then can easily retrieve the info. Of course, it can be retrieved from FDT but you need to maintain a library to get the content.

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/b9226766-163b-5c84-6127-f636dfec72d8%40ventanamicro.com.

[Sunil V L]

Hi Tuan,

There is already libfdt and recently it is added in MdePkg itself so that it is easier to use in different packages without introducing cyclic dependencies. IMO, defining GUID for ISA is not necessary. We may need more things from DT like this (ex: CBO sizes etc). Better to use FDT library for all such use cases.

Thanks,

Sunil

[Tuan Phan]

Hi Sunil,

It is not about functionality, it is about the easy to use from user perspective. Yes you can using libfdt to retrieve anything from FDT. My view is fdt should only visible before DXE phase as it is the meant to pass information from M-mode to firmware. All info that EDK2 DXE needed should be prepared in HOB.

Also, there no need to pass FDT configuration to Linux if we only want ACPI support only.

[Sunil V L]

Hi Tuan,

On Mon, Jul 31, 2023 at 04:47:08PM +0000, Tuan Phan wrote:
> Hi Sunil,

> It is not about functionality, it is about the easy to use from user perspective. Yes you can using libfdt to retrieve anything from FDT. My view is fdt should only visible before DXE phase as it is the meant to pass information from M-mode to firmware. All info that EDK2 DXE needed should be prepared in HOB.

I understand your point. My concern is, we will need lot of data from
FDT anyway and some may not be really CPU related (ex: external
interrupt controllers). So, I don't see any need to duplicating all
those data in HOB structures. Also, we are not really simplifying
anything since FDT needs to be parsed anyway by Pre-DXE phase to
populate the HOB. So, we will be just left shifting the code. I would
rather have a simple SEC/PEI phases to do very minimum, absolutely
required things. AFAIK, there is no restriction in tianocore design
that FDT can not be used at DXE phase.

> Also, there no need to pass FDT configuration to Linux if we only want ACPI support only.

OTOH, the data is duplicated for DT case. Even for ACPI platforms, we
should use dynamic table generation using DT.

Thanks,
Sunil

>
> From: Sunil V L <sun...@ventanamicro.com>
> Date: Monday, July 31, 2023 at 9:37 AM
> To: Tuan Phan <tp...@ventanamicro.com>
> Cc: Dhaval Sharma <dha...@rivosinc.com>, Atish Kumar Patra <ati...@rivosinc.com>, RISC-V Firmware Exchange <fw-ex...@riscv.org>, Andrei Warkentin <andrei.w...@intel.com>, Aaron Durbin <adu...@rivosinc.com>, Anup Patel <apa...@ventanamicro.com>
> Subject: Re: ISA string discovery for FW
>
> Hi Tuan,
>
> There is already libfdt and recently it is added in MdePkg itself so that it is easier to use in different packages without introducing cyclic dependencies. IMO, defining GUID for ISA is not necessary. We may need more things from DT like this (ex: CBO sizes etc). Better to use FDT library for all such use cases.
>
> Thanks,
>
> Sunil
>
>
> On 31/07/23 21:49, Tuan Phan wrote:
> Hi Sunil,
>

> On Mon, Jul 31, 2023 at 4:46 AM Sunil V L <sun...@ventanamicro.com<mailto:sun...@ventanamicro.com>> wrote:
>
> Hi Dhaval,
> On 31/07/23 10:08, Dhaval Sharma wrote:
> To clarify this further there are two aspects:
>

> 1. A need to have a specification for various ways of ISA string discovery in FW. For now I am focused on this point.
> 2. How that discovery happens could be a combination of DT, SBI extension (or even HOB in case of UEFI). This point is mute if we do not think #1 is required.

> So first I wanted to discuss if adding some sort of standardization helps. That would mean, we add details on how ISA discovery happens as part of BRS. My point was that such clarity will help different FW developers given that ISA string discovery is quite fundamental to the boot flow.
>

> Take a look at this<https://github.com/tianocore/edk2/compare/master...andreiw:edk2-rv-wip:remove_riscv_fw_ctx> patch where we are planning to define EFI_HOB_TYPE_CPU_RISCV. Would it not be better to add an ISA string as part of this HOB? To me it sounds more natural to have it there instead of parsing it from DT when PI is passing this information to Dxe. While in OpenSBI as you mentioned below DT might make more sense.

>
> Unless I am missing something, creating a HOB for FDT and pass to next phase is a standard across architectures and it is required anyway to install FDT pointer UEFI configuration table for DT based systems. Why should we define new thing for ISA alone when we can pass entire FDT?
> => If the info that is standard then it is better to export in HOB so any modules/drivers just provide GUID then can easily retrieve the info. Of course, it can be retrieved from FDT but you need to maintain a library to get the content.
>
> Thanks,
>
> Sunil
>
> I am just documenting my thoughts here and if required we could add broader audience (through PRS or BRS forums) but wanted to see if there are more thoughts from FW team in this line.
> =D
>

> On Fri, Jul 28, 2023 at 1:02 PM Atish Kumar Patra <ati...@rivosinc.com<mailto:ati...@rivosinc.com>> wrote:

> > To unsubscribe from this group and stop receiving emails from it, send an email to fw-exchange...@riscv.org<mailto:fw-exchange%2Bunsu...@riscv.org>.

> > To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/CAAxYnhTac8deMuik69JVk1s6v6bMA_4hKEC2J__WhO%2BZL9pj4g%40mail.gmail.com.
>
>
> --
> Thanks!
> =D
> --
> You received this message because you are subscribed to the Google Groups "RISC-V Firmware Exchange" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to fw-exchange...@riscv.org<mailto:fw-exchange...@riscv.org>.
> To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/b9226766-163b-5c84-6127-f636dfec72d8%40ventanamicro.com<https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/b9226766-163b-5c84-6127-f636dfec72d8%40ventanamicro.com?utm_medium=email&utm_source=footer>.

[Dhaval Sharma]

Hi,

Further following up on the thread, we had a discussion about ISA string in BRS yesterday. General consensus was that it deserves consideration but adding requirements for a spec (how exactly to do it) would put constraints on developers. We would rather wait for stronger scenarios where it crosses the higher bar which justifies these constraints. So for now the guidance is to leave it as is.

For the adjacent discussion we are having regarding passing CPU information from PEI to Dxe, one point I realize is that in the end we are just wrapping one spec within another (by creating FDT HOB). 🙂. From a PI spec perspective, DT HOB is still a custom HOB as its type is not defined as part of the spec. I am thinking so many systems are reliant on DT today, it is already a widely accepted HOB type (for RV and ARM), should we just request to add it in the PI spec? It practically does not hurt even without that though.

=D

--

Thanks!

=D

[Sunil V L]

Hi Dhaval,

I think you are right. I guess Andrei's proposal would document in the spec if it removes FIRMWARE_CONTEXT and suggests to use the gFdtHobGuid.

Thanks,

Sunil

[Sunil V L]

Hi All,

I am rethinking on this and leaning towards the HOB data. The reason is,
few modules/libraries like CMO need to check for extension even in SEC
phase. I was initially thinking to provide an interface which checks the
extension support in ISA string from FDT and modules can cache it in a
global variable. However, typically SEC phase starts in XIP where we can
not set global variables. Traversing FDT every time is not a good
idea. So, I think we don't have any other option other than adding it in
CPU HOB. Thoughts?

Thanks!
Sunil

[Dhaval Sharma]

Yes Sunil, that is something I just investigated and my comment on these 2 options:

1. FDT traversal. Yes does not sound efficient but then we do not have a lot of applications of CMO in Sec mode either.
2. HOB. Sounds like a better option to me as once we create it we can leverage it all through.

=D

--

Thanks!

=D

[Warkentin, Andrei]

Yes, FIRMWARE_CONTEXT is gone from PI spec (at least in the sense that the ECR has been accepted).

 

So I haven’t yet created a PI spec ECR to introduce a special RISCV CPU HOB. But I will, the code first implementation is already done and tested with RiscVVirt – this is the next natural step (followed by tons of painful cleanup to U5Pkg, but I digress). This will only contain the boot hart ID at the moment. Really, if the UEFI implementation wishes to rely on parsing an FDT passed to it (a solid idea), then there’s already the gFdtHobGuid mechanism to do just that.

 

I’m a big believer that FDT is a useful tool for firmware autoconfiguration. I.e. it’s okay to make it available to the DXE phase – this doesn’t mean that it gets exposed to the OS, necessarily. Systems that boot ACPI OSes won’t expose the FDT (but may use the FDT, for example, to generate ACPI tables or configure BS drivers).

 

As far as the ISA string detection… you could get it from the DT or use a custom ecall if you don’t like DT. Or maybe you just get it straight from your HV-populated ACPI tables (in a VM). Different choices may be valid. What I don’t think is necessary is sticking the ISA string in a HOB.

 

A

To unsubscribe from this group and stop receiving emails from it, send an email to fw-exchange...@riscv.org.
To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/8076c007-28b7-6a2f-470a-b8baa908156f%40ventanamicro.com.

[Warkentin, Andrei]

Okay, I can see the reasoning where we can parse out some useful info into the CPU hob, like CMO info (i.e. not just an ISA string but useful data).

 

Did you have a list of such parameters in mind? This way when we propose the PI Spec ECR we won’t have to immediately churn again on it in a few months…

 

A

[Sunil V L]

Currently, I see CMO (Zicbo*), Sstc and Svpbmt extensions are required
to be discovered in EDK2. Except CBO, all other are uses/initialized
only in DXE. But any BASE class library/module can be used in SEC. So,
it is a good idea to use same mechanism for all extension discovery.

I was thinking to have a 64-bit field in the Hob along with boot
hart ID. Each bit will represent only those extensions EDK2 uses. I
hope 64 bits are sufficient. Otherwise, we can have 2 64-bit fields and
one reserved for future (crypto extensions may be required too). In
addition, we also need to have CBO block size information. This is the
minimum information we need. While I think the HOB data should be
absolute minimum which is required in Pre-DXE phase also, I don't think
we can fix this since new extensions are being defined frequently and
can't say for sure EDK2 will not need any thing else. So, is it possible
to have a generic structure like extension_data in CPU HOB which can be
extended without updating PI spec?

I agree we should not duplicate entire ISA string in HOB. Any other
platform data like APLIC info etc should be retrieved from FDT itself in
DXE phase.

On Wed, Aug 09, 2023 at 09:51:10PM +0000, Warkentin, Andrei wrote:
> Okay, I can see the reasoning where we can parse out some useful info into the CPU hob, like CMO info (i.e. not just an ISA string but useful data).
>
> Did you have a list of such parameters in mind? This way when we propose the PI Spec ECR we won’t have to immediately churn again on it in a few months…
>
> A
>
> From: Dhaval Sharma <dha...@rivosinc.com>
> Sent: Wednesday, August 9, 2023 1:22 AM
> To: Sunil V L <sun...@ventanamicro.com>
> Cc: Tuan Phan <tp...@ventanamicro.com>; Atish Kumar Patra <ati...@rivosinc.com>; RISC-V Firmware Exchange <fw-ex...@riscv.org>; Warkentin, Andrei <andrei.w...@intel.com>; Aaron Durbin <adu...@rivosinc.com>; Anup Patel <apa...@ventanamicro.com>
> Subject: Re: ISA string discovery for FW
>
> Yes Sunil, that is something I just investigated and my comment on these 2 options:
>

> 1. FDT traversal. Yes does not sound efficient but then we do not have a lot of applications of CMO in Sec mode either.
> 2. HOB. Sounds like a better option to me as once we create it we can leverage it all through.
> =D

> > > On Fri, Jul 28, 2023 at 1:02 PM Atish Kumar Patra <ati...@rivosinc.com<mailto:ati...@rivosinc.com><mailto:ati...@rivosinc.com<mailto:ati...@rivosinc.com>>> wrote:

> > > > To unsubscribe from this group and stop receiving emails from it, send an email to fw-exchange...@riscv.org<mailto:fw-exchange%2Bunsu...@riscv.org><mailto:fw-exchange%2Bunsu...@riscv.org<mailto:fw-exchange%252Buns...@riscv.org>>.

> > > > To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/CAAxYnhTac8deMuik69JVk1s6v6bMA_4hKEC2J__WhO%2BZL9pj4g%40mail.gmail.com.
> > >
> > >
> > > --
> > > Thanks!
> > > =D
> > > --
> > > You received this message because you are subscribed to the Google Groups "RISC-V Firmware Exchange" group.

> > > To unsubscribe from this group and stop receiving emails from it, send an email to fw-exchange...@riscv.org<mailto:fw-exchange%2Bunsu...@riscv.org><mailto:fw-exchange...@riscv.org<mailto:fw-exchange%2Bunsu...@riscv.org>>.

> > > To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/b9226766-163b-5c84-6127-f636dfec72d8%40ventanamicro.com<https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/b9226766-163b-5c84-6127-f636dfec72d8%40ventanamicro.com?utm_medium=email&utm_source=footer>.
>
>
> --
> Thanks!
> =D
>

> --
> You received this message because you are subscribed to the Google Groups "RISC-V Firmware Exchange" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to fw-exchange...@riscv.org.
> To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/PH8PR11MB6856494F37C8CDCFF959DA7A8312A%40PH8PR11MB6856.namprd11.prod.outlook.com.

[Dhaval Sharma]

If I summarize discussion so far, here is what I understand:

1. Bit fields would work but then this is an evolving story. So we can not have a fixed set in the spec.
2. Each of these fields may come with additional data that needs to be provided (CBO size). So it has to be more than bit fields.
3. We could define a more generic HOB but then it can not be boundless. There has to be at least version controlled definition of this structure maintained somewhere. RV can decide how/when it gets updated.
4. Use HOB ONLY where necessary, DT otherwise where possible. So is it possible to keep the scope of this HOB very limited (mostly for pre-Dxe stages)?

To be more specific on top of what Sunil alluded to, can we have a RISCV generic HOB which contains a header followed by a dataset. Header contains version information for the structure. Version of the structure we can maintain outside of PI (somewhere in the RV domain). Does that make sense?

=D

--

Thanks!

=D

[Warkentin, Andrei]

I brought up the topic of extending the RISCV CPU HOB in the PIWG call. Because it’s clear that we’re going to have to evolve it over time.

 

The consensus is that we should have a version field in there (as the first field). And then we can add whatever new fields we want. Revving the spec is not the problem (but we should of course think first before adding stuff).

 

We can go with a bitfield (and just add extra fields). I don’t see anything too wrong with that. At the same time, the RISCVCPU HOB really needs to be used for either:

• Aspects that are not covered by something existing (DT, SBI). Boot hart id is a good example here.
• Aspects that are used so often that relying on on something existing (DT, SBI) would add unreasonable overhead.

[Warkentin, Andrei]

Coming back to this… how does this sound for a definition? HartCaps is 32-bit to ensure 64-bit alignment for BootHartId. We can always add further HartCapsX fields if we need them (and we’re not going to be adding a bit for every extension…)

 

//

// EFI_HOB_CPU_RISCV Version.

//

#define EFI_HOB_CPU_RISCV_VERSION_1 0x0001

 

//

// EFI_HOB_CPU_RISCV HartCaps.

//

#define EFI_RISCV_CAP_SSTC    0x0001

#define EFI_RISCV_CAP_ZICBOM  0x0002

#define EFI_RISCV_CAP_ZICBOZ  0x0004

#define EFI_RISCV_CAP_ZICBOP  0x0008

#define EFI_RISCV_CAP_SVPBMT  0x0010

 

///

/// Describes additional RISC-V processor information,

/// on top of information provided by EFI_HOB_CPU.

///

typedef struct {

  ///

  /// The HOB generic header. Header.HobType = EFI_HOB_TYPE_CPU_RISCV.

  ///

  EFI_HOB_GENERIC_HEADER    Header;

  ///

  /// The version number of the EFI_HOB_TYPE_CPU_RISCV HOB definition,

  /// which may evolve over time.

  ///

  UINT32                    Version;

  ///

  /// Describes universal capabilities that are expected to be queried

  /// and used by multiple Tiano components, making it beneficial for

  /// discovery info to be cached.

  ///

  UINT32                    HartCaps;

  ///

  /// Only valid if EFI_RISCV_CAP_ZICBOM or EFI_RISCV_CAP_ZICBOP is

  /// set in HartCaps.

  ///

  UINT32                    CboBlockSize;

  ///

  /// Only valid if EFI_RISCV_CAP_ZICBOZ is set in HartCaps.

  ///

  UINT32                    CboZeroBlockSize;

  ///

  /// Booting hart ID.

  ///

  UINT64                    BootHartId;

} EFI_HOB_CPU_RISCV;

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/SN7PR11MB6849EA08D8A421BA410B15778313A%40SN7PR11MB6849.namprd11.prod.outlook.com.

[Sunil V L]

Thanks Andrei. LGTM.

BTW, I couldn't find anything in the spec that CBO block sizes for
management and prefetch operations should be same. They may be same in
general but is it guaranteed somehow?

Thanks,

Sunil

> *From:* Warkentin, Andrei <andrei.w...@intel.com>
> *Sent:* Thursday, August 10, 2023 4:52 AM
> *To:* Dhaval Sharma <dha...@rivosinc.com>; Sunil V L
> <sun...@ventanamicro.com>
> *Cc:* Tuan Phan <tp...@ventanamicro.com>; Atish Kumar Patra

> <ati...@rivosinc.com>; RISC-V Firmware Exchange
> <fw-ex...@riscv.org>; Aaron Durbin <adu...@rivosinc.com>; Anup
> Patel <apa...@ventanamicro.com>

> *Subject:* RE: ISA string discovery for FW

>
> I brought up the topic of extending the RISCV CPU HOB in the PIWG
> call. Because it’s clear that we’re going to have to evolve it over time.
>
> The consensus is that we should have a version field in there (as the
> first field). And then we can add whatever new fields we want. Revving
> the spec is not the problem (but we should of course think first
> before adding stuff).
>
> We can go with a bitfield (and just add extra fields). I don’t see
> anything too wrong with that. At the same time, the RISCVCPU HOB
> really needs to be used for either:
>

> * Aspects that are not covered by something existing (DT, SBI). Boot

> hart id is a good example here.

> * Aspects that are used so often that relying on on something

> existing (DT, SBI) would add unreasonable overhead.
>
> A
>

> *From:* Dhaval Sharma <dha...@rivosinc.com>
> *Sent:* Thursday, August 10, 2023 12:44 AM
> *To:* Sunil V L <sun...@ventanamicro.com>
> *Cc:* Warkentin, Andrei <andrei.w...@intel.com>; Tuan Phan

> <tp...@ventanamicro.com>; Atish Kumar Patra <ati...@rivosinc.com>;
> RISC-V Firmware Exchange <fw-ex...@riscv.org>; Aaron Durbin
> <adu...@rivosinc.com>; Anup Patel <apa...@ventanamicro.com>

> *Subject:* Re: ISA string discovery for FW

>
> If I summarize discussion so far, here is what I understand:
>

> 1. Bit fields would work but then this is an evolving story. So we

> can not have a fixed set in the spec.

> 2. Each of these fields may come with additional data that needs to

> be provided (CBO size). So it has to be more than bit fields.

> 3. We could define a more generic HOB but then it can not be

> boundless. There has to be at least version controlled definition
> of this structure maintained somewhere. RV can decide how/when it
> gets updated.

> 4. Use HOB ONLY where necessary, DT otherwise where possible. So is

> <mailto:fw-exchange%252Buns...@riscv.org>><mailto:fw-exchange%2Bunsu...@riscv.org
> <mailto:fw-exchange%252Buns...@riscv.org><mailto:fw-exchange%252Buns...@riscv.org
> <mailto:fw-exchange%25252Bun...@riscv.org>>>.

> > > > > To view this discussion on the web visit
> https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/CAAxYnhTac8deMuik69JVk1s6v6bMA_4hKEC2J__WhO%2BZL9pj4g%40mail.gmail.com.
> > > >
> > > >
> > > > --
> > > > Thanks!
> > > > =D
> > > > --
> > > > You received this message because you are subscribed to the
> Google Groups "RISC-V Firmware Exchange" group.
> > > > To unsubscribe from this group and stop receiving emails
> from it, send an email to fw-exchange...@riscv.org

> <mailto:fw-exchange%2Bunsu...@riscv.org><mailto:fw-exchange%2Bunsu...@riscv.org
> <mailto:fw-exchange%252Buns...@riscv.org>><mailto:fw-exchange...@riscv.org

> <mailto:fw-exchange%2Bunsu...@riscv.org><mailto:fw-exchange%2Bunsu...@riscv.org
> <mailto:fw-exchange%252Buns...@riscv.org>>>.
> > > > To view this discussion on the web visit

> https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/b9226766-163b-5c84-6127-f636dfec72d8%40ventanamicro.com<https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/b9226766-163b-5c84-6127-f636dfec72d8%40ventanamicro.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/b9226766-163b-5c84-6127-f636dfec72d8%40ventanamicro.com?utm_medium=email&utm_source=footer>>.
> >
> >
> > --
> > Thanks!
> > =D
> >
> > --
> > You received this message because you are subscribed to the
> Google Groups "RISC-V Firmware Exchange" group.
> > To unsubscribe from this group and stop receiving emails from

> it, send an email to fw-exchange...@riscv.org

> <mailto:fw-exchange%2Bunsu...@riscv.org>.
> > To view this discussion on the web visit

> https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/PH8PR11MB6856494F37C8CDCFF959DA7A8312A%40PH8PR11MB6856.namprd11.prod.outlook.com.
>
>
> --
>
> Thanks!
>
> =D
>
> --
> You received this message because you are subscribed to the Google
> Groups "RISC-V Firmware Exchange" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fw-exchange...@riscv.org.
> To view this discussion on the web visit
> https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/SN7PR11MB6849EA08D8A421BA410B15778313A%40SN7PR11MB6849.namprd11.prod.outlook.com

> <https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/SN7PR11MB6849EA08D8A421BA410B15778313A%40SN7PR11MB6849.namprd11.prod.outlook.com?utm_medium=email&utm_source=footer>.
>

[Warkentin, Andrei]

The CMO spec section 2.7 is a bit terse but appears to imply management and prefetch use the same block size.

I.e.:

The initial set of CMO extensions requires the following information to be discovered by software:
• The size of the cache block for management and prefetch instructions
• The size of the cache block for zero instructions
• CBIE support at each privilege level

But an extra field isn't worth the headache to think about it. I'll just have 3 block size fields.

A

> <sun...@ventanamicro.com<mailto:sun...@ventanamicro.com><mailto:suni
> l...@ventanamicro.com<mailto:sun...@ventanamicro.com>>>

> <ati...@rivosinc.com<mailto:ati...@rivosinc.com><mailto:atishp@rivosinc.

> com<mailto:ati...@rivosinc.com>>>
> > wrote:
> > > > > On Thu, Jul 27, 2023 at 9:36 PM Dhaval Sharma
> >

> <dha...@rivosinc.com<mailto:dha...@rivosinc.com><mailto:dhaval@rivosin

> <sun...@ventanamicro.com<mailto:sun...@ventanamicro.com><mailto:suni
> l...@ventanamicro.com<mailto:sun...@ventanamicro.com>>>

> exchange+u...@riscv.org
> > <mailto:fw-exchange%2Bunsu...@riscv.org><mailto:fw-

[Dhaval Sharma]

Hi Andrei,

wrt CMO, I think we need reflection of xenvcfg in this HOB. Just saying CMO is enabled does not say (Invalid/clean/flush). This is where it will probably get tricky for such features right?

If we want to make generic we will have to add metadata for such features for it to be effective. Or, we could use PCDs for that (in general we do not expect this PCD to change in most cases).

=D

--

Thanks!

=D

[Warkentin, Andrei]

Hi Dhaval,

 

Good point… we could accommodate this via adding another field, envcfg, which would reflect the capabilities in the *current* privilege level.

 

Would that solve the problem? The field could be, in an implementation:

1. Hardcoded
2. Populated via PCDs
3. Fetched from DT
4. Queried via ECALL

[Sunil V L]

Hi Andrei, Dhaval,

My understanding was, if M-mode FW alters the behavior reflected in
menvcfg, it will update the FDT accordingly before switching to S-mode.
I believe linux also follows the same convention. Also, I don't think
there is any binding in DT defined for this or an SBI call either.
PCD/hardcoded values is not a good idea IMO.

Regards,
Sunil

On 09/09/23 13:23, Warkentin, Andrei wrote:
>
> Hi Dhaval,
>
> Good point… we could accommodate this via adding another field,

> *envcfg*, which would reflect the capabilities in the **current**

> privilege level.
>
> Would that solve the problem? The field could be, in an implementation:
>

> 1. Hardcoded
> 2. Populated via PCDs
> 3. Fetched from DT
> 4. Queried via ECALL

>
> A
>
> *From:* Dhaval Sharma <dha...@rivosinc.com>

> *Sent:* Saturday, September 9, 2023 1:18 AM
> *To:* Warkentin, Andrei <andrei.w...@intel.com>
> *Cc:* Sunil V L <sun...@ventanamicro.com>; Tuan Phan

> > c.com <http://c.com><mailto:dha...@rivosinc.com>>>

> <mailto:exchange%252Buns...@riscv.org>
> > >     <mailto:fw-exchange%252Buns...@riscv.org
> <mailto:fw-exchange%25252Bun...@riscv.org>>><mailto:fw-
> > exchange%2Bunsu...@riscv.org
> <mailto:exchange%252Buns...@riscv.org>
> > >     <mailto:fw-exchange%252Buns...@riscv.org
> <mailto:fw-exchange%25252Bun...@riscv.org>><mailto:fw-
> > exchange%252Buns...@riscv.org
> <mailto:exchange%25252Bun...@riscv.org>
> > >     <mailto:fw-exchange%25252Bun...@riscv.org
> <mailto:fw-exchange%2525252Bu...@riscv.org>>>>.

> > >     > > > > To view this discussion on the web visit
> > > https://groups.google.com/a/riscv.org/d/msgid/fw-
> > exchange/CAAxYnhTac8deMuik69JVk1s6v6bMA_4hKEC2J__WhO%2BZL9pj4g

> > %40mail.gmail.com <http://40mail.gmail.com>.

> > >     > > >
> > >     > > >
> > >     > > > --
> > >     > > > Thanks!
> > >     > > > =D
> > >     > > > --
> > >     > > > You received this message because you are subscribed
> to the
> > >     Google Groups "RISC-V Firmware Exchange" group.
> > >     > > > To unsubscribe from this group and stop receiving emails
> > >     from it, send an email to
> fw-exchange...@riscv.org
> <mailto:fw-exchange%2Bunsu...@riscv.org>

> > >     <mailto:fw-exchange%2Bunsu...@riscv.org

> <mailto:fw-exchange%252Buns...@riscv.org>><mailto:fw-
> > exchange%2Bunsu...@riscv.org

> <mailto:exchange%252Buns...@riscv.org>
> > >     <mailto:fw-exchange%252Buns...@riscv.org
> <mailto:fw-exchange%25252Bun...@riscv.org>>><mailto:fw-
> > exchange+u...@riscv.org
> <mailto:exchange%2Bunsu...@riscv.org>
> > >     <mailto:fw-exchange%2Bunsu...@riscv.org

> <mailto:fw-exchange%252Buns...@riscv.org>><mailto:fw-
> > exchange%2Bunsu...@riscv.org

> <mailto:exchange%252Buns...@riscv.org>
> > >     <mailto:fw-exchange%252Buns...@riscv.org

> <mailto:fw-exchange%25252Bun...@riscv.org>>>>.
> > >     > > > To view this discussion on the web visit
> > >

> https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/b9226766-
> > 163b-5c84-6127-
> > f636dfec72d8%40ventanamicro.com
> <http://40ventanamicro.com><https://groups.google.com/a/riscv.org/d
> > /msgid/fw-exchange/b9226766-163b-5c84-6127-
> > f636dfec72d8%40ventanamicro.com?utm_medium=email&utm_source=foot
> <http://40ventanamicro.com?utm_medium=email&utm_source=foot>

> > er
> > >   
>  <https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/b9226766-
> > 163b-5c84-6127-
> > f636dfec72d8%40ventanamicro.com?utm_medium=email&utm_source=foot

> <http://40ventanamicro.com?utm_medium=email&utm_source=foot>

> > er>>.
> > >     >
> > >     >
> > >     > --
> > >     > Thanks!
> > >     > =D
> > >     >
> > >     > --
> > >     > You received this message because you are subscribed to the
> > >     Google Groups "RISC-V Firmware Exchange" group.
> > >     > To unsubscribe from this group and stop receiving emails
> from
> > >     it, send an email to fw-exchange...@riscv.org
> <mailto:fw-exchange%2Bunsu...@riscv.org>

> > >     <mailto:fw-exchange%2Bunsu...@riscv.org

> <mailto:fw-exchange%252Buns...@riscv.org>>.
> > >     > To view this discussion on the web visit
> > > https://groups.google.com/a/riscv.org/d/msgid/fw-

> > exchange/PH8PR11MB6856494F37C8CDCFF959DA7A8312A%40PH8PR11MB6
> > 856.namprd11.prod.outlook.com
> <http://856.namprd11.prod.outlook.com>.

> > >
> > >
> > > --
> > >
> > > Thanks!
> > >
> > > =D
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "RISC-V Firmware Exchange" group.
> > > To unsubscribe from this group and stop receiving emails from
> it, send
> > > an email to fw-exchange...@riscv.org
> <mailto:fw-exchange%2Bunsu...@riscv.org>.
> > > To view this discussion on the web visit
> > > https://groups.google.com/a/riscv.org/d/msgid/fw-

> > exchange/SN7PR11MB684
> > >
> > 9EA08D8A421BA410B15778313A%40SN7PR11MB6849.namprd11.prod.outlo
> > ok.com <http://ok.com>
> > > <https://groups.google.com/a/riscv.org/d/msgid/fw-
> > exchange/SN7PR11MB6849EA08D8A421BA410B15778313A%40SN7PR11MB6
> > 849.namprd11.prod.outlook.com?utm_medium=email&utm_source=footer
> <http://849.namprd11.prod.outlook.com?utm_medium=email&utm_source=footer>>.
> > >
>
>
> --
>
> Thanks!
>
> =D
>

[Dhaval Sharma]

Hi Sunil,

Are you referring to the fact that there is no way for s-mode (SEC or whoever is creating CPU HOB) to know xenvcfg because DT/SBI do not have such interfaces available?

Since DT only suggests that Zicbom is available and it can not provide additional information about CBIE/CBFE I am thinking if we do not use PCD or SBI call, what is the other way out?

=D

--

Thanks!

=D

[Anup Patel]

On Sun, Sep 10, 2023 at 11:46 PM Dhaval Sharma <dha...@rivosinc.com> wrote:
>
> Hi Sunil,
> Are you referring to the fact that there is no way for s-mode (SEC or whoever is creating CPU HOB) to know xenvcfg because DT/SBI do not have such interfaces available?
> Since DT only suggests that Zicbom is available and it can not provide additional information about CBIE/CBFE I am thinking if we do not use PCD or SBI call, what is the other way out?

Zicbom in ISA string implies that related cbo.* instructions are
available. This is the way even Linux interprets Zicbom in ISA string.

Why do you need the exact state of CBIE and CDFE bits ?

Regards,
Anup

> To unsubscribe from this group and stop receiving emails from it, send an email to fw-exchange...@riscv.org.
> To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/CAAxYnhSO2-7u1XahyXT28T-H06rdb2M-F6f4ePtTJey6GPUY6g%40mail.gmail.com.

[Dhaval Sharma]

There are a couple of different modes i.e. in case of CBIE:

00: The instruction raises an illegal instruction or virtual instruction exception

01: The instruction is executed and performs a flush operation

11: The instruction is executed and performs an invalidate operation

So 01 is the one that directly maps to CBO (Invalidate) enabled. But 00- do we map it to "Not enabled" or "Enabled through exceptions" and hence don't care for s-mode?

Also in a hypothetical scenario (allowed by spec) where Instruction Invd is enabled but Clean and Flush cause exceptions, like in above case s-mode can assume that it is the same as "enabled"?

I will investigate a bit more on this and come back.

=D

--

Thanks!

=D

[Anup Patel]

On Mon, Sep 11, 2023 at 11:09 AM Dhaval Sharma <dha...@rivosinc.com> wrote:
>
> There are a couple of different modes i.e. in case of CBIE:
> 00: The instruction raises an illegal instruction or virtual instruction exception
> 01: The instruction is executed and performs a flush operation
> 11: The instruction is executed and performs an invalidate operation
>
> So 01 is the one that directly maps to CBO (Invalidate) enabled. But 00- do we map it to "Not enabled" or "Enabled through exceptions" and hence don't care for s-mode?
> Also in a hypothetical scenario (allowed by spec) where Instruction Invd is enabled but Clean and Flush cause exceptions, like in above case s-mode can assume that it is the same as "enabled"?

The supervisor software does not need to know whether a particular CBO
instruction is actual HW instruction or trap-n-emulated by SBI
implementation (M-mode or HS-mode).

The presence of Zicbom in ISA string implies CBO maintenance
instructions are functionally available to the supervisor software. It
is SBI implementation's choice whether CBO instructions are directly
allowed for supervisor mode or trap-n-emulated in software.

Regards,
Anup

[Dhaval Sharma]

Alright sounds good. If we go with that assumption which sounds reasonable, we can avoid having extra xenvcfg parameters. Thanks.

=D

--

Thanks!

=D

[Warkentin, Andrei]

Ok, acknowledged.

 

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/CAAxYnhSP5dA6xW%3DThL0B%2BrDmgs_EE%3De8ofVjmboyE_-OUcQMgA%40mail.gmail.com.

[Dhaval Sharma]

Hi Andrei,

Revisiting this thread as I hit a scenario where I was looking for a similar HOB. If you have plans to add it, I will wait to hear from you.

=D

--

Thanks!

=D

[Rafael Sene]

+ @赵思齐(重刄) (Siqi Zhao), how is leading the Unified Discovery TG.

Obrigado | Thank You

Rafael Peria de Sene

Technical Program Manager, RISC-V

Phone: +55 19 98153 9778

E-mail: raf...@riscv.org

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/fw-exchange/CAAxYnhSqNxFF2ABrBPoRkjj0YfM39STmDH49Z0mZWT4mndm-6g%40mail.gmail.com.

[Rafael Sene]

On 10 Jun 2024 at 09:47:28, Rafael Sene <raf...@riscv.org> wrote:

how

Who*