1. tech-unixplatformspec@lists.riscv.org
  2. Messages
   Date   
OS-A SEE TG Meeting 2022/09/12

Aaron Durbin
 

Hi All,

We had our first meeting this past Monday (2022/09/12).

I pushed the notes to GitHub. As a reminder each group in RVI has their own folder for stashing collateral. For OS-A SEE TG, the folder is here. Under that there is a Meetings folder that has a doc that has a link to the GitHub notes in addition to the meeting presentations. The other, and most important doc, is the Future Topics doc where people can put their concerns/comments/requests to cover in the next meeting(s).

We'll have our next meeting on Monday 2022/09/26 at 9am PT. It's already been put on the tech.meetings@... calendar. We hope to have an initial framework in the spec repository as well as some initial content that we can discuss.

2022/09/12

  • Meeting Presentation
  • Went over the Charter
    • Discussed what is in scope for OS-A SEE
    • Paul W. asked about hardware requirements. In alignment with the Charter, we should be focusing on compatibility across RISC-V systems for loading and running operating systems. Hardware requirements should fall under the Platform specifications.
    • Additionally Kumar indicated SW view of the world should be the focus.
  • Paul brought up a distinction of feature / device binding required in both early and later stages of kernel startup.
  • Target Audience of OS-A SEE? Ideally would be standar operating system distributions to further expand the ecosystem. Users of the RISC-V systems would benefit, but it's important to allow operating system distributions to target a conformant spec.
  • psABI would not fall into the purview of the OS-A SEE spec. Reason: Kumar syas focus should be on ability to run same OS on multiple implementations.
  • ACPI vs DT. Acknowledge we need to support both. May want to allow an OS to choose which one to support (or both) instead of mandating both. Allows for OS vendors to define their own product. Topic to still be discussed.
  • Need to start framework of document and start seeding content.


Thank you.

-Aaron
Re: Access problem of mtimercmp in a platform with multiple MTIMER devices

Anup Patel
 

On Wed, Sep 7, 2022 at 8:44 AM Tianyi Xia via lists.riscv.org
<tianshi.xty=alibaba-inc.com@...> wrote:

each "cluster" can have its own unique mmio address for mtimecmp (which may or may not be accessible to other "clusters")

I think this description is better.



Assume there are two clusters，each cluster have two cores，and each cluster have there own MTIMER device. The mmio address of mtimecmp for each hart may like this:

Cluster0

Core0: base0+0x0000_0000

Core1: base0+0x0000_0008

Cluster1

Core0: base1+0x0000_0000

Core1: base1+0x0000_0008

Base0 is the MTIER device base address of cluster0, Base1 is the MTIER device base address of cluster0. the mtimecmp of cluster0 core0 may or maynot be accessible to cluster1, depending on the implementation. If core try to access mtimecmp of other cluster, the action of the access may be write ignore read zero.


The latter sounds like it would be difficult for SW

I think in a platform with multiple MTIMER devices, the mmio address of mtimecmp should be unique to distinguish different MTIMER devices. The hardware can set regular base address to different Mtimer devices. In the above example, assuming base is 0, then base1 may be set to 0x0000_0010. If cluster0 has four cores, then base1 may be set to 0x0000_0020.Then from a software perspective, all mtimecmp registers are addressed consecutively.
This case is already handled by ACLINT device tree bindings. We
just need two separate MTIMER DT nodes where the mtimecmp
base address will be different in each DT node.

Please refer to the latest OpenSBI sources.

Regards,
Anup
Re: Access problem of mtimercmp in a platform with multiple MTIMER devices

Allen Baum
 

That makes sense, but it does mean that discovery gets more complicated, and (maybe) you need to build separate device trees for each.
But maybe that has to happen anyway? I don't know if DT can be parameterized based on HartID, but that would greatly simplify the work.

On Tue, Sep 6, 2022 at 8:14 PM Tianyi Xia via lists.riscv.org <tianshi.xty=alibaba-inc.com@...> wrote:

each "cluster" can have its own unique mmio address for mtimecmp (which may or may not be accessible to other "clusters")

I think this description is better.

 

Assume there are two clusters，each cluster have two cores，and each cluster have there own MTIMER device. The mmio address of mtimecmp for each hart may like this:

Cluster0

    Core0: base0+0x0000_0000

    Core1: base0+0x0000_0008

Cluster1

    Core0: base1+0x0000_0000

    Core1: base1+0x0000_0008

Base0 is the MTIER device base address of cluster0, Base1 is the MTIER device base address of cluster0. the mtimecmp of cluster0 core0 may or maynot be accessible to cluster1,  depending on the implementation. If core try to access mtimecmp of other cluster, the action of the access may be write ignore read zero.


The latter sounds like it would be difficult for SW

I think in a platform with multiple MTIMER devices, the mmio address of mtimecmp should be unique to distinguish different MTIMER devices. The hardware can set regular base address to different Mtimer devices. In the above example, assuming base is 0, then base1 may be set to 0x0000_0010. If cluster0 has four cores, then base1 may be set to 0x0000_0020.Then from a software perspective, all mtimecmp registers are addressed consecutively.

 


 
Re: Access problem of mtimercmp in a platform with multiple MTIMER devices

Tianyi Xia <tianshi.xty@...>
 

each "cluster" can have its own unique mmio address for mtimecmp (which may or may not be accessible to other "clusters")

I think this description is better.

 

Assume there are two clusters，each cluster have two cores，and each cluster have there own MTIMER device. The mmio address of mtimecmp for each hart may like this:

Cluster0

    Core0: base0+0x0000_0000

    Core1: base0+0x0000_0008

Cluster1

    Core0: base1+0x0000_0000

    Core1: base1+0x0000_0008

Base0 is the MTIER device base address of cluster0, Base1 is the MTIER device base address of cluster0. the mtimecmp of cluster0 core0 may or maynot be accessible to cluster1,  depending on the implementation. If core try to access mtimecmp of other cluster, the action of the access may be write ignore read zero.


The latter sounds like it would be difficult for SW

I think in a platform with multiple MTIMER devices, the mmio address of mtimecmp should be unique to distinguish different MTIMER devices. The hardware can set regular base address to different Mtimer devices. In the above example, assuming base is 0, then base1 may be set to 0x0000_0010. If cluster0 has four cores, then base1 may be set to 0x0000_0020.Then from a software perspective, all mtimecmp registers are addressed consecutively.

 


 
First Platform Runtime Services (PRS) TG meeting 09/07 8AM PDT

atishp@...
 

Hi All,
Apologies for cross posting multiple lists. Just wanted to reach out to the maximum audience as this is a short notice to set up the first meeting.

This is just a quick notice that the first PRS TG meeting has been scheduled. It will take place on Wednesday, Sep 7th, at 8am Pacific. You should see the meeting on the RISC-V Tech Meetings calendar shortly.

Agenda:
  • Introductions (10 min)
  • Discuss regular meeting time and cadence (10 min)
  • Review charter (20 min)
  • Order of SBI/ACPI proposal discussions (10 min)

Looking forward to meeting everyone!

Regards,
Atish
Re: [RISC-V] Platform Runtime Services preliminary charter & meetings

atishp@...
 

Hi All,
The doodle poll indicates that the 8AM PDT Wednesday is the most preferred slot. This will probably conflict with hypervisor SIG meetings once in a while. We will reschedule that meeting whenever required.
I will schedule the first PRS meeting for tomorrow at 8AM PDT. This is probably a short notice but I want to get the ball rolling as soon as possible and avoid more conflicts.

I will send the agenda and meeting links in a separate email. We are very excited to get started!


On Thu, Sep 1, 2022 at 11:45 AM Atish Kumar Patra <atishp@...> wrote:

Hi All,

We are pleased to announce the early formation of Platform Runtime Services(PRS) Task Group with Atish Patra from Rivos as the acting chair and Sunil VL from ventana as the acting vice chair.
The PRS TG will drive various runtime services specifications i.e. SBI, UEFI & ACPI in RISC-V.

The TG details, including the charter can be found at

Charter: https://github.com/riscv-admin/prs/blob/main/CHARTER.md
The community page: https://lists.riscv.org/g/tech-prs
Mailing list address : tech-prs@...
Github Repo : https://github.com/riscv-admin/prs

We encourage you to participate in the PRS TG. Please “Join This Group” by clicking the blue button on the bottom of the community page:
Please review the charter if you are interested and let us know your feedback.

We are planning to have biweekly meetings to discuss various ACPI ECRs and SBI improvement proposals first.

Here is a doodle poll for the least conflicting time slots for the zoom meeting.

https://doodle.com/meeting/organize/id/b2vWxn1b


Please select your preferred slots by Tuesday(6th Sep). We will schedule the meeting as per the majority preference.

Here are some of the SBI & ACPI proposals that need to be discussed (not necessarily in this order).

SBI:

  • Debug Console SBI extension
  • Steal time accounting
  • AP-TEE SBI extension
  • Attestation SBI extension
  • SBI PMU improvements (including snapshot)
  • SBI debug extension
ACPI:

  • MADT - RINTC
  • MADT - AIA RINTC
  • MADT - AIA IMSIC/APLIC
  • RHCT
UEFI:
We don't have any proposals in flight right now.


Regards,
Atish, Sunil
Re: Access problem of mtimercmp in a platform with multiple MTIMER devices

Allen Baum
 

The implication of that is that either
 - there is an mmio address that can access different instantiations of mtime/mtimecmp for each requesting hart (depending on the "cluster")
 - each "cluster" can have its own unique mmio address for mtimecmp (which may or may not be accessible to other "clusters")

Is one or either of those a preferred option? The latter sounds like it would be difficult for SW

On Tue, Sep 6, 2022 at 12:16 AM Tianyi Xia via lists.riscv.org <tianshi.xty=alibaba-inc.com@...> wrote:

In the SiFive Core-Local Interruptor (CLINT) device , a core can access the mtimcmp register of all cores in the platform.

In the ACLINT spec, If a platform implements multiple MTIMER devices, such as multiple clusters, each cluster implements one MTIMER device, then a core may not be able to access the MTIMER devices of other clusters.

As I understand, it is not necessary for a core to access the mtimecmp of other cores. Is it possible to add a recommended software usage method to the ACLINT spec, for example, it is recommended that the software only use a core to access its own mtimcmp register, but not access mtimcmp of other cores. This can avoid the problem that the software uses a core to access the MTIMER devices of other clusters, but the hardware cannot support it.
Access problem of mtimercmp in a platform with multiple MTIMER devices

Tianyi Xia <tianshi.xty@...>
 

In the SiFive Core-Local Interruptor (CLINT) device , a core can access the mtimcmp register of all cores in the platform.

In the ACLINT spec, If a platform implements multiple MTIMER devices, such as multiple clusters, each cluster implements one MTIMER device, then a core may not be able to access the MTIMER devices of other clusters.

As I understand, it is not necessary for a core to access the mtimecmp of other cores. Is it possible to add a recommended software usage method to the ACLINT spec, for example, it is recommended that the software only use a core to access its own mtimcmp register, but not access mtimcmp of other cores. This can avoid the problem that the software uses a core to access the MTIMER devices of other clusters, but the hardware cannot support it.
Call for Chair/Vice-Chair Candidates for Platform Runtime Services(PRS) TG

atishp@...
 

cross-posting for more visibility. 

---------- Forwarded message ---------
From: Atish Kumar Patra <atishp@...>
Date: Thu, Sep 1, 2022 at 11:55 AM
Subject: Call for Chair/Vice-Chair Candidates for Platform Runtime Services(PRS) TG
To: <tech-announce@...>


This is a call for chair and vice-chair candidates for the recently created Platform Runtime Services(PRS) TG.


All candidates must submit a biography (bio) and statements of intent by Sep 15th 2022. The policy describing this process is here.


The current draft charter of the PRS TG can be found here.


Nomination process, requirements, and duties:

If you would like to be included or know someone who should be, please send an email to help@... with the candidate's name, member affiliation, qualifications, a small bio and a statement of intent (both less than 250 words each).


Qualifications include:
- Experience with ACPI/UEFI specifications development 
- Familiarity with RISC-V SBI specification
- Experience with systems software (OS, hypervisors, drivers, firmware)
- Familiarity with RISC-V ISA specifications

Duties as chair/vice-chair (see Best Practices document) include:

- Collaboration with existing task groups within the RISC-V Foundation

- Seek contributions/collaborations while keeping focus on TG charter

- Publish meeting minutes

- Serve as an editor for some of the proposals

- Community interactions through meetings, mail list, GitHub, Wiki

- Respond to queries within 48 hours

- Manage and run regular meetings as per the group charter

- Attend weekly tech-chairs meetings



Thanks,
Atish, Sunil
[RISC-V] Platform Runtime Services preliminary charter & meetings

atishp@...
 

Hi All,

We are pleased to announce the early formation of Platform Runtime Services(PRS) Task Group with Atish Patra from Rivos as the acting chair and Sunil VL from ventana as the acting vice chair.
The PRS TG will drive various runtime services specifications i.e. SBI, UEFI & ACPI in RISC-V.

The TG details, including the charter can be found at

Charter: https://github.com/riscv-admin/prs/blob/main/CHARTER.md
The community page: https://lists.riscv.org/g/tech-prs
Mailing list address : tech-prs@...
Github Repo : https://github.com/riscv-admin/prs

We encourage you to participate in the PRS TG. Please “Join This Group” by clicking the blue button on the bottom of the community page:
Please review the charter if you are interested and let us know your feedback.

We are planning to have biweekly meetings to discuss various ACPI ECRs and SBI improvement proposals first.

Here is a doodle poll for the least conflicting time slots for the zoom meeting.

https://doodle.com/meeting/organize/id/b2vWxn1b


Please select your preferred slots by Tuesday(6th Sep). We will schedule the meeting as per the majority preference.

Here are some of the SBI & ACPI proposals that need to be discussed (not necessarily in this order).

SBI:

  • Debug Console SBI extension
  • Steal time accounting
  • AP-TEE SBI extension
  • Attestation SBI extension
  • SBI PMU improvements (including snapshot)
  • SBI debug extension
ACPI:

  • MADT - RINTC
  • MADT - AIA RINTC
  • MADT - AIA IMSIC/APLIC
  • RHCT
UEFI:
We don't have any proposals in flight right now.


Regards,
Atish, Sunil
Re: OS-A SEE TG Meeting Thurs Sept 1 @ 9am PT

Aaron Durbin
 

Hi All,

I received some feedback that they had some conflicts with the proposed time. I adjusted the calendar invite to be for Mon Sept 12th at 8am PT. I will still send out slides prior to that so we can collaborate prior and set us up for an efficient meeting.

Regards,

-Aaron

On Fri, Aug 26, 2022 at 2:41 PM Aaron Durbin <adurbin@...> wrote:
Hi All,

I put a meeting on the RISC-V calendar for Thursday September 1 @ 9am PT. I'll send the slides out earlier in the week for people to critique and add suggestions of topics. We'll go over the charter and discuss various requirements we think should go into the OS-A SEE specification (and its dependencies).

I hope people can make it. I know it's less than a week's notice, but I believe with some persistence we can complete most of the spec by the end of the year.

-Aaron
OS-A SEE TG Meeting Thurs Sept 1 @ 9am PT

Aaron Durbin
 

Hi All,

I put a meeting on the RISC-V calendar for Thursday September 1 @ 9am PT. I'll send the slides out earlier in the week for people to critique and add suggestions of topics. We'll go over the charter and discuss various requirements we think should go into the OS-A SEE specification (and its dependencies).

I hope people can make it. I know it's less than a week's notice, but I believe with some persistence we can complete most of the spec by the end of the year.

-Aaron
Re: [RISC-V] [tech-aia] [RISC-V] [tech-unixplatformspec] Review request for ACPI ECRs

Aaron Durbin
 



On Thu, Aug 4, 2022 at 10:16 AM Sunil V L <sunilvl@...> wrote:
Hi Aaron,

On Thu, Aug 04, 2022 at 09:16:21AM -0600, Aaron Durbin wrote:
> On Wed, Aug 3, 2022 at 8:17 AM Sunil V L <sunilvl@...> wrote:
>
> > Hi All,
> >
> > We plan to send below two ECRs to UEFI forum on 08/08/2022. These two
> > ECRs don't have any dependency on any unfrozen specs.
> > Getting these two ECRs accepted by UEFI forum would help us to enable big
> > chunk of ACPI infrastructure patches for RISC-V.
> >
> >          a) RHCT
> >
> > https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing
>
>
> I don't think we should submit this one until we settle on how we convey
> behaviors outside of an ISA string. I suspect that will change so we should
> anticipate that. Right now we have ISA string plus CMO parameters as
> specific RHCT Nodes. Are we concerned about timing on adoption to push this
> in its current form? I ask because I'd rather not have this set in stone
> only for us to quickly come back and say "stop using these fields. we have
> a new node/mechanism to convey this information".  What do you think?

I was under the impression that it is decided not to use the
extension names mentioned in profile spec. Sorry I didn't know you are
still working with TSC to conclude on this.

In that case, let's remove the CMO structure from the RHCT and submit
the ECR. CMO structure is not really mandatory for OS.

>
> I brought up this topic in the TSC meeting this week as I indicated I
> would. I need to work with some others to formalize the direction, but
> that's going to take a little more time.

Right. My preference is, to keep sending multiple revisions of the ECRs
with incremental changes, while making sure we don't obsolete things
fairly quickly as you mentioned. I think removing CMO strucutre helps us
to take care of both requirements. When you get clarity from TSC, we can
add in next revision. What do you think?

Sounds good. As long as we don't annoy anyone with a stream ECR updates to the same table I think that's a fine approach.
 

Thanks
Sunil
>
>
> >
> >          b)MADT RINTC
> >
> > https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing
>
>
> Aside from maybe wordsmithing a little more for clarity purposes (based on
> commentary) I think this one seems fine from my standpoint.
>
>
> >
> > Please feel free to provide comments in the document before 08/08.
> > The documents and feedback will be archived in the same folder.
> >
> > Thanks
> > Sunil
> >
> > On Tue, Jul 05, 2022 at 10:46:18PM +0530, Sunil V L via lists.riscv.org
> > wrote:
> > > Hi All,
> > >
> > > Thanks a lot for great feedback over last week on the ECRs. I have
> > > created version 2 of the ECRs addressing most of the comments. We will be
> > > discussing this version of the ECRs in this week's meeting. Please
> > > provide your comments in this version of the documents.
> > >
> > > 1) Non-AIA ECRs
> > >         a) RHCT - version 2:
> > >
> > https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing
> > >         b)MADT RINTC - version 2:
> > >
> > https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing
> > > 2) AIA ECRs
> > >         a)  MADT - AIA RINTC (version 2) :
> > >
> > https://docs.google.com/document/d/1LBKD1gyi6kOfE3V2WiFOPz1h4MlmxHDj7vkjjfSygBo/edit?usp=sharing
> > >         b) MADT - AIA IMSIC/APLIC version 2:
> > >
> > https://docs.google.com/document/d/1zDainvcxD14eawsyc3y1s78zP7ruefyGzcsP1bBak3w/edit?usp=sharing
> > >
> > > PoC Code has been updated at same location as earlier.
> > >
> > > Thanks
> > > Sunil
> > >
> > > On Tue, Jun 21, 2022 at 11:18:02PM +0530, Sunil V L via lists.riscv.org
> > wrote:
> > > > Hi All,
> > > >
> > > > Please review below Engineering Change Request (ECR) to update the ACPI
> > > > spec for enabling basic ACPI support for RISC-V.
> > > >
> > > > 1) Add INTC structure in MADT Table -
> >
> >
> > > >
> > https://docs.google.com/document/d/13YdZzUv0mRHBotdy4Qjqrzb-83mjM31AyEXXfgodcNw/edit?usp=sharing
> > > >
> > > > 2) Add new RISC-V Hart Capabilities Table (RHCT).
> > > >
> > https://docs.google.com/document/d/1-hQMzSNTEfNqudIENhGxrrb0Yr5MEo4NcZwXZlvdx6k/edit?usp=sharing
> > > >
> > > > 3) Add AIA interrupt controllers in MADT table
> > > >
> > https://docs.google.com/document/d/1rbdXsON4OMJ0QB3UvkfkIa8hdySbWArIKqPRUli7AU0/edit?usp=sharing
> > > >
> > > > First two ECRs do not have a dependency on any RVI specs which are not
> > > > frozen. But the third ECR  has a dependency on AIA spec to be frozen.
> > > > Hence this AIA ECR will NOT be sent to UEFI forum until AIA spec is
> > frozen.
> > > >
> > > > The PoC for these ECRs is complete and ACPI enabled Linux boots on qemu
> > > > platform. Below are links to the source code for the PoC.
> > > > qemu - https://github.com/ventanamicro/qemu/tree/dev-upstream
> > > > edk2 - https://github.com/ventanamicro/edk2/tree/dev-upstream
> > > > edk2-platforms -
> > https://github.com/ventanamicro/edk2-platforms/tree/dev-upstream
> > > > linux - https://github.com/ventanamicro/linux/tree/dev-upstream
> > > >
> > > > You can find how to build and test these changes in this link -
> > > >
> > https://github.com/riscv-non-isa/riscv-acpi/wiki/PoC-:-How-to-build-and-test-ACPI-enabled-kernel
> > > >
> >
> >
> > > > You can provide the feedback by commenting in the document itself. I am
> > > > hoping to send at least first two ECRs to UEFI forum by 8th August
> > 2022.
> > > > So, appreciate your help to improve these ECRs before 4th August 2022
> > > > (45 days from today).
> > > >
> >
> >
> > > > Feel free to reach out if you have any questions.
> > > >
> >
> >
> > > > Thanks!
> > > > Sunil
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
>
>
>
>
>

Re: [RISC-V] [tech-aia] [RISC-V] [tech-unixplatformspec] Review request for ACPI ECRs

Sunil V L
 

Hi Aaron,

On Thu, Aug 04, 2022 at 09:16:21AM -0600, Aaron Durbin wrote:
On Wed, Aug 3, 2022 at 8:17 AM Sunil V L <sunilvl@...> wrote:

Hi All,

We plan to send below two ECRs to UEFI forum on 08/08/2022. These two
ECRs don't have any dependency on any unfrozen specs.
Getting these two ECRs accepted by UEFI forum would help us to enable big
chunk of ACPI infrastructure patches for RISC-V.

a) RHCT

https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing

I don't think we should submit this one until we settle on how we convey
behaviors outside of an ISA string. I suspect that will change so we should
anticipate that. Right now we have ISA string plus CMO parameters as
specific RHCT Nodes. Are we concerned about timing on adoption to push this
in its current form? I ask because I'd rather not have this set in stone
only for us to quickly come back and say "stop using these fields. we have
a new node/mechanism to convey this information". What do you think?
I was under the impression that it is decided not to use the
extension names mentioned in profile spec. Sorry I didn't know you are
still working with TSC to conclude on this.

In that case, let's remove the CMO structure from the RHCT and submit
the ECR. CMO structure is not really mandatory for OS.


I brought up this topic in the TSC meeting this week as I indicated I
would. I need to work with some others to formalize the direction, but
that's going to take a little more time.
Right. My preference is, to keep sending multiple revisions of the ECRs
with incremental changes, while making sure we don't obsolete things
fairly quickly as you mentioned. I think removing CMO strucutre helps us
to take care of both requirements. When you get clarity from TSC, we can
add in next revision. What do you think?

Thanks
Sunil



b)MADT RINTC

https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing

Aside from maybe wordsmithing a little more for clarity purposes (based on
commentary) I think this one seems fine from my standpoint.



Please feel free to provide comments in the document before 08/08.
The documents and feedback will be archived in the same folder.

Thanks
Sunil

On Tue, Jul 05, 2022 at 10:46:18PM +0530, Sunil V L via lists.riscv.org
wrote:
Hi All,

Thanks a lot for great feedback over last week on the ECRs. I have
created version 2 of the ECRs addressing most of the comments. We will be
discussing this version of the ECRs in this week's meeting. Please
provide your comments in this version of the documents.

1) Non-AIA ECRs
a) RHCT - version 2:
https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing
b)MADT RINTC - version 2:
https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing
2) AIA ECRs
a) MADT - AIA RINTC (version 2) :
https://docs.google.com/document/d/1LBKD1gyi6kOfE3V2WiFOPz1h4MlmxHDj7vkjjfSygBo/edit?usp=sharing
b) MADT - AIA IMSIC/APLIC version 2:
https://docs.google.com/document/d/1zDainvcxD14eawsyc3y1s78zP7ruefyGzcsP1bBak3w/edit?usp=sharing

PoC Code has been updated at same location as earlier.

Thanks
Sunil

On Tue, Jun 21, 2022 at 11:18:02PM +0530, Sunil V L via lists.riscv.org
wrote:
Hi All,

Please review below Engineering Change Request (ECR) to update the ACPI
spec for enabling basic ACPI support for RISC-V.

1) Add INTC structure in MADT Table -

https://docs.google.com/document/d/13YdZzUv0mRHBotdy4Qjqrzb-83mjM31AyEXXfgodcNw/edit?usp=sharing

2) Add new RISC-V Hart Capabilities Table (RHCT).
https://docs.google.com/document/d/1-hQMzSNTEfNqudIENhGxrrb0Yr5MEo4NcZwXZlvdx6k/edit?usp=sharing

3) Add AIA interrupt controllers in MADT table
https://docs.google.com/document/d/1rbdXsON4OMJ0QB3UvkfkIa8hdySbWArIKqPRUli7AU0/edit?usp=sharing

First two ECRs do not have a dependency on any RVI specs which are not
frozen. But the third ECR has a dependency on AIA spec to be frozen.
Hence this AIA ECR will NOT be sent to UEFI forum until AIA spec is
frozen.

The PoC for these ECRs is complete and ACPI enabled Linux boots on qemu
platform. Below are links to the source code for the PoC.
qemu - https://github.com/ventanamicro/qemu/tree/dev-upstream
edk2 - https://github.com/ventanamicro/edk2/tree/dev-upstream
edk2-platforms -
https://github.com/ventanamicro/edk2-platforms/tree/dev-upstream
linux - https://github.com/ventanamicro/linux/tree/dev-upstream

You can find how to build and test these changes in this link -
https://github.com/riscv-non-isa/riscv-acpi/wiki/PoC-:-How-to-build-and-test-ACPI-enabled-kernel

You can provide the feedback by commenting in the document itself. I am
hoping to send at least first two ECRs to UEFI forum by 8th August
2022.
So, appreciate your help to improve these ECRs before 4th August 2022
(45 days from today).

Feel free to reach out if you have any questions.

Thanks!
Sunil
Re: [RISC-V] [tech-aia] [RISC-V] [tech-unixplatformspec] Review request for ACPI ECRs

Aaron Durbin
 



On Wed, Aug 3, 2022 at 8:17 AM Sunil V L <sunilvl@...> wrote:
Hi All,

We plan to send below two ECRs to UEFI forum on 08/08/2022. These two
ECRs don't have any dependency on any unfrozen specs.
Getting these two ECRs accepted by UEFI forum would help us to enable big
chunk of ACPI infrastructure patches for RISC-V.

         a) RHCT
         https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing

I don't think we should submit this one until we settle on how we convey behaviors outside of an ISA string. I suspect that will change so we should anticipate that. Right now we have ISA string plus CMO parameters as specific RHCT Nodes. Are we concerned about timing on adoption to push this in its current form? I ask because I'd rather not have this set in stone only for us to quickly come back and say "stop using these fields. we have a new node/mechanism to convey this information".  What do you think?

I brought up this topic in the TSC meeting this week as I indicated I would. I need to work with some others to formalize the direction, but that's going to take a little more time.
 

         b)MADT RINTC
         https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing

Aside from maybe wordsmithing a little more for clarity purposes (based on commentary) I think this one seems fine from my standpoint. 



Please feel free to provide comments in the document before 08/08.
The documents and feedback will be archived in the same folder.

Thanks
Sunil

On Tue, Jul 05, 2022 at 10:46:18PM +0530, Sunil V L via lists.riscv.org wrote:
> Hi All,
>
> Thanks a lot for great feedback over last week on the ECRs. I have
> created version 2 of the ECRs addressing most of the comments. We will be
> discussing this version of the ECRs in this week's meeting. Please
> provide your comments in this version of the documents.
>
> 1) Non-AIA ECRs
>         a) RHCT - version 2:
>         https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing
>         b)MADT RINTC - version 2:
>         https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing
> 2) AIA ECRs
>         a)  MADT - AIA RINTC (version 2) :
>         https://docs.google.com/document/d/1LBKD1gyi6kOfE3V2WiFOPz1h4MlmxHDj7vkjjfSygBo/edit?usp=sharing
>         b) MADT - AIA IMSIC/APLIC version 2:
>         https://docs.google.com/document/d/1zDainvcxD14eawsyc3y1s78zP7ruefyGzcsP1bBak3w/edit?usp=sharing
> 
> PoC Code has been updated at same location as earlier.
>
> Thanks
> Sunil
>
> On Tue, Jun 21, 2022 at 11:18:02PM +0530, Sunil V L via lists.riscv.org wrote:
> > Hi All,
> >
> > Please review below Engineering Change Request (ECR) to update the ACPI
> > spec for enabling basic ACPI support for RISC-V.
> >
> > 1) Add INTC structure in MADT Table -                                                                                                                                                                     
> > https://docs.google.com/document/d/13YdZzUv0mRHBotdy4Qjqrzb-83mjM31AyEXXfgodcNw/edit?usp=sharing
> >
> > 2) Add new RISC-V Hart Capabilities Table (RHCT).
> > https://docs.google.com/document/d/1-hQMzSNTEfNqudIENhGxrrb0Yr5MEo4NcZwXZlvdx6k/edit?usp=sharing
> >
> > 3) Add AIA interrupt controllers in MADT table
> > https://docs.google.com/document/d/1rbdXsON4OMJ0QB3UvkfkIa8hdySbWArIKqPRUli7AU0/edit?usp=sharing
> >
> > First two ECRs do not have a dependency on any RVI specs which are not
> > frozen. But the third ECR  has a dependency on AIA spec to be frozen.
> > Hence this AIA ECR will NOT be sent to UEFI forum until AIA spec is frozen.
> >
> > The PoC for these ECRs is complete and ACPI enabled Linux boots on qemu
> > platform. Below are links to the source code for the PoC.
> > qemu - https://github.com/ventanamicro/qemu/tree/dev-upstream
> > edk2 - https://github.com/ventanamicro/edk2/tree/dev-upstream
> > edk2-platforms - https://github.com/ventanamicro/edk2-platforms/tree/dev-upstream
> > linux - https://github.com/ventanamicro/linux/tree/dev-upstream
> >
> > You can find how to build and test these changes in this link -
> > https://github.com/riscv-non-isa/riscv-acpi/wiki/PoC-:-How-to-build-and-test-ACPI-enabled-kernel
> >                                                                                                                                                                                                           
> > You can provide the feedback by commenting in the document itself. I am
> > hoping to send at least first two ECRs to UEFI forum by 8th August 2022.
> > So, appreciate your help to improve these ECRs before 4th August 2022
> > (45 days from today).
> >                                                                                                                                                                                                           
> > Feel free to reach out if you have any questions.
> >                                                                                                                                                                                                           
> > Thanks!
> > Sunil
> >
> >
> >
> >
> >
>
>
>
>
>





SBI Debug Console Extension Proposal (Draft v4)

Anup Patel
 

Hi All,

Based on feedback, below is the updated draft proposal of the
SBI Debug Console Extension ...

The motivations behind this proposal is as follows:
1) There is no new SBI extension replacing the legacy SBI v0.1
putchar() and getchar() calls. These legacy SBI v0.1 calls are
now disabled by default in Linux and will be eventually deprecated.
We need a replacement at least for the SBI v0.1 putchar() which
is widely used for early prints in various OSes and Bootloaders.
2) The OS-A Platforms (or SEE) specification need to mandate
a particular type of UART (8250, ns16550, or SiFive) as a standard
way for boot-time early prints in supervisor-mode software. Using
SBI debug console extension, the OS-A Platforms (or SEE)
specifications don't need to mandate any type of UART.
3) The legacy SBI v0.1 putchar() only supports printing one
character at a time. For some of the hypervisors (particularly KVM),
SBI based early prints (i.e. earlycon=sbi) is slow because each
SBI v0.1 putchar() trap will be forwarded to the KVM user-space
(KVMTOOL or QEMU).

In other words, the SBI debug console extension defines a standard
way for boot-time early prints in supervisor-mode software.

We have completed the proof-of-concept implementation of this
SBI extension proposal. Refer, "riscv_sbi_dbcn_v1" branch in the
following repos:
https://github.com/avpatel/opensbi.git
https://github.com/avpatel/linux.git
https://github.com/avpatel/kvmtool.git

Please review it and provide your feedback.

Regards,
Anup

SBI Debug Console Extension (EID #0x4442434E "DBCN")
====================================================

The debug console extension defines a generic mechanism for boot
time early prints from supervisor-mode software which allows users
to catch boot-time issues in supervisor-mode software.

This extension replaces the legacy console putchar (EID #0x01)
extension with following improvements:
1) It follows the new calling convention defined by the SBI v1.0
(or higher) specification.
2) It allows supervisor software to print multiple characters
in a single SBI call.

Some of the functions defined by this SBI extension have physical
memory as parameters for input and/or output. This physical memory
parameter MUST satisfy following requirements:
1) The SBI implementation MUST check that the supervisor-mode
software is allowed to read and write the specified physical
memory on the calling HART.
2) The SBI implementation MUST access the specified physical
memory using the PMA attribute.
Note: If the supervisor-mode software access the same physical
memory using memory type different from PMA then a loss of
coherence or unexpected memory ordering may occur and the
invoking software should follow the rules and sequences defined
in the RISC-V Svpbmt specification to prevent the loss of
coherence and memory ordering.

If the underlying physical console has extra bits for error checking
(or correction) then these extra bits should be handled by the SBI
implementation.

Function: Console Puts (FID #0)
-------------------------------

struct sbiret sbi_debug_console_puts(unsigned long num_chars,
uint64_t base_addr)

Print a specified input string on the debug console.

The `num_chars` parameter specifies the number of characters (or
bytes) in the input string whereas `base_addr` parameter specifies
the physical base address of the input string.

This is a blocking SBI call and will only return after printing all
characters of the input string.

Errors:
SBI_SUCCESS - Characters printed successfully.
SBI_ERR_INVALID_ADDRESS - The string pointed by `num_chars` and `base_addr`
parameters is not entirely accessible to
supervisor-mode.
SBI_ERR_FAILED - Failed to print characters due to I/O errors.
Re: SBI Debug Console Extension Proposal (Draft v3)

Anup Patel
 

Hi,

On Wed, Aug 3, 2022 at 1:27 PM 洛佳 Luo Jia <me@...> wrote:

Hi Group,

I have an idea on addr_lo and addr_hi combination. What will happen if we ask supervisor to provide the
string address in a probable virtual address? In this way the supervisor won't need to convert it to physical
address, and we can save one argument for future designs to refer to. If machine mode firmware need to
read the supervisor accesible address, it uses mstatus.TVM bit to achieve this. By this way the machine
accesses the string parameter the same way the supervisor does.

Considering difference of physical and virtual address spacees (e.g. on RV32 Sv32 has 34-bit physical address),
if the supervisor does not use virtual memory, it only reads lower 32 bit of physical address, which is the
same limit of how machine mode firmware would read the memory.

By this way we have `usize` as parameter:

fn debug_console_print(supervisor_address: usize, length_bytes: usize) -> SbiRet { ... }
There are two major issues in passing virtual address of string:

1) A rogue supervisor software can pass a virtual address mapped to a
physical address not accessible to it.
2) To access a string by virtual address, the SBI implementation (M-mode
firmware and hypervisors) end-up using unpriv load/store instructions.
These unpriv load/store instructions can potentially trap for hypervisor
because the guest OS can swap-out pages while the hypervisor is
trying to access it. Further in-case of nested virtualization, the unpriv
load/store instructions always trap to the host hypervisor so accessing
string by virtual address becomes extremely slow for guest hypervisor.

Due to the above reasons, we avoid using virtual addresses as
parameters in newer SBI calls for SBI v0.2 (higher).

Regards,
Anup


... other than combining different parts to form the final address.

Luo Jia
Re: Review request for ACPI ECRs

Sunil V L
 

Hi All,

We plan to send below two ECRs to UEFI forum on 08/08/2022. These two
ECRs don't have any dependency on any unfrozen specs.
Getting these two ECRs accepted by UEFI forum would help us to enable big
chunk of ACPI infrastructure patches for RISC-V.

a) RHCT
https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing
b)MADT RINTC
https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing

Please feel free to provide comments in the document before 08/08.
The documents and feedback will be archived in the same folder.

Thanks
Sunil

On Tue, Jul 05, 2022 at 10:46:18PM +0530, Sunil V L via lists.riscv.org wrote:
Hi All,

Thanks a lot for great feedback over last week on the ECRs. I have
created version 2 of the ECRs addressing most of the comments. We will be
discussing this version of the ECRs in this week's meeting. Please
provide your comments in this version of the documents.

1) Non-AIA ECRs
a) RHCT - version 2:
https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing
b)MADT RINTC - version 2:
https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing
2) AIA ECRs
a) MADT - AIA RINTC (version 2) :
https://docs.google.com/document/d/1LBKD1gyi6kOfE3V2WiFOPz1h4MlmxHDj7vkjjfSygBo/edit?usp=sharing
b) MADT - AIA IMSIC/APLIC version 2:
https://docs.google.com/document/d/1zDainvcxD14eawsyc3y1s78zP7ruefyGzcsP1bBak3w/edit?usp=sharing

PoC Code has been updated at same location as earlier.

Thanks
Sunil

On Tue, Jun 21, 2022 at 11:18:02PM +0530, Sunil V L via lists.riscv.org wrote:
Hi All,

Please review below Engineering Change Request (ECR) to update the ACPI
spec for enabling basic ACPI support for RISC-V.

1) Add INTC structure in MADT Table -
https://docs.google.com/document/d/13YdZzUv0mRHBotdy4Qjqrzb-83mjM31AyEXXfgodcNw/edit?usp=sharing

2) Add new RISC-V Hart Capabilities Table (RHCT).
https://docs.google.com/document/d/1-hQMzSNTEfNqudIENhGxrrb0Yr5MEo4NcZwXZlvdx6k/edit?usp=sharing

3) Add AIA interrupt controllers in MADT table
https://docs.google.com/document/d/1rbdXsON4OMJ0QB3UvkfkIa8hdySbWArIKqPRUli7AU0/edit?usp=sharing

First two ECRs do not have a dependency on any RVI specs which are not
frozen. But the third ECR has a dependency on AIA spec to be frozen.
Hence this AIA ECR will NOT be sent to UEFI forum until AIA spec is frozen.

The PoC for these ECRs is complete and ACPI enabled Linux boots on qemu
platform. Below are links to the source code for the PoC.
qemu - https://github.com/ventanamicro/qemu/tree/dev-upstream
edk2 - https://github.com/ventanamicro/edk2/tree/dev-upstream
edk2-platforms - https://github.com/ventanamicro/edk2-platforms/tree/dev-upstream
linux - https://github.com/ventanamicro/linux/tree/dev-upstream

You can find how to build and test these changes in this link -
https://github.com/riscv-non-isa/riscv-acpi/wiki/PoC-:-How-to-build-and-test-ACPI-enabled-kernel

You can provide the feedback by commenting in the document itself. I am
hoping to send at least first two ECRs to UEFI forum by 8th August 2022.
So, appreciate your help to improve these ECRs before 4th August 2022
(45 days from today).

Feel free to reach out if you have any questions.

Thanks!
Sunil
Re: SBI Debug Console Extension Proposal (Draft v3)

洛佳 Luo Jia
 

Hi Group,

I have an idea on addr_lo and addr_hi combination. What will happen if we ask supervisor to provide the
string address in a probable virtual address? In this way the supervisor won't need to convert it to physical
address, and we can save one argument for future designs to refer to. If machine mode firmware need to
read the supervisor accesible address, it uses mstatus.TVM bit to achieve this. By this way the machine
accesses the string parameter the same way the supervisor does.

Considering difference of physical and virtual address spacees (e.g. on RV32 Sv32 has 34-bit physical address),
if the supervisor does not use virtual memory, it only reads lower 32 bit of physical address, which is the
same limit of how machine mode firmware would read the memory.

By this way we have `usize` as parameter:

fn debug_console_print(supervisor_address: usize, length_bytes: usize) -> SbiRet { ... }

... other than combining different parts to form the final address.

Luo Jia
Re: SBI Debug Console Extension Proposal (Draft v3)

Anup Patel
 

On Mon, Jul 25, 2022 at 5:11 PM Darius Rad <darius@...> wrote:

On Mon, Jul 25, 2022 at 10:04:52AM +0530, Anup Patel wrote:

Function: Console Puts (FID #0)
-------------------------------

struct sbiret sbi_debug_console_puts(unsigned long addr_lo,
unsigned long addr_hi,
unsigned long num_chars)

Print a specified input string on the debug console.

The physical base address and size of the string to be printed is
derived from parameters as follows:
1) `addr_lo` parameter specifies the lower XLEN bits of the string
physical base address.
2) `addr_hi` parameter specifies the string physical base address
right shifted by XLEN.
It is really necessary to have two long parameters for a physical address
on RV64? Clearly this is necessary for RV32, where the maximum physical
address is greater than XLEN, but that is not the case for RV64.

Why not use long long, which is 8 bytes on both RV32 and RV64 (on the
respective ABIs, that is)? Or use a different function signature for RV32
and RV64, with two parameters for the former and one for the latter?
For SBI spec, we have avoided separate function signatures for RV32
and RV64 so better to prefer other options.

If we want to combine "addr_lo" and "addr_hi" into one parameter then
uint64_t is better and consistent with other parts of SBI spec as well.

Regards,
Anup


3) `num_chars` parameter specifies the size of the string as the
number of characters (or bytes).
// darius
21 - 40 of 1850