tech-unixplatformspec@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

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

Hi Aaron, 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

By Sunil V L · #1817 ·

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

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

By Aaron Durbin · #1816 ·

SBI Debug Console Extension Proposal (Draft v4)

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

By Anup Patel · #1815 ·

Re: SBI Debug Console Extension Proposal (Draft v3)

Hi, 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

By Anup Patel · #1814 ·

Re: Review request for ACPI ECRs

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

By Sunil V L · #1813 ·

Re: SBI Debug Console Extension Proposal (Draft v3)

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

By 洛佳 Luo Jia · #1812 ·

Re: SBI Debug Console Extension Proposal (Draft v3)

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

By Anup Patel · #1811 ·

Re: SBI Debug Console Extension Proposal (Draft v3)

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

By Darius Rad · #1810 ·

Re: SBI Debug Console Extension Proposal (Draft v3)

<heinrich.schuchardt@...> wrote: Okay, I will update the text. Yes, the accessibility check on physical address parameters is very important for SBI implementation (M-mode firmware,

By Anup Patel · #1809 ·

Re: SBI Debug Console Extension Proposal (Draft v3)

We should also cover the case that only a part of the memory area is accessible by S-mode. %s/accessible/entirely accessible/ It is unclear if the SBI is obliged to check S-mode accessibility. The

By Heinrich Schuchardt · #1808 ·

SBI Debug Console Extension Proposal (Draft v3)

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

By Anup Patel · #1807 ·

SBI Debug Trigger Extension Proposal (Draft v4)

Hi All, To support native debugging in S-mode and VS-mode, we need a SBI Debug Trigger extension which complements the Sdtrig extension. Below is the draft proposal of the SBI Debug Trigger

By Anup Patel · #1806 ·

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

My point is that the information, regardless of format, needs to be conveyed in some manner to the OS. There's no getting around that aspect. We need to identify 1. all the things the OS needs and 2.

By Aaron Durbin · #1805 ·

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

Allen, Rereading your comment, I realised that something was off (as I didn't have a line 244) — looks like I missed the additional tabs on the inline preview of the sheet in the mail

By Philipp Tomsich <philipp.tomsich@...> · #1804 ·

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

But the problem is that a profile is just putting an extension-style name (e.g. Zi* or Ss*) to a specific combination of an option or parameter, and a specific value for that option or parameter.

By Greg Favor · #1803 ·

Re: [RISC-V][privileged-software] [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

This was a point I tried to make in another thread about tech-config and profiles. Support for a profile implies support for all the extensions mandated by the profile (but still leaves unspecified

By Greg Favor · #1802 ·

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

Ah, never mind. My version of the spreadsheet opens to sheet3, and that's what has the complete list. The other sheets were used to develop this one. I will rename the sheet and put it in the front.

By Allen Baum · #1801 ·

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

They are marked in the spreadsheet as "Ignored in v1.0", for what it's worth, but I could make it more obvious (or better, move them to a separate sheet-- done)

By Allen Baum · #1800 ·

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

Alan, Given the recent troubles with people having taken extensions in the priv/unpriv spec documents as being official even though they are listed as unratified, I would suggest not listing

By Greg Favor · #1799 ·

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

Allen, You should check with the tpm's as to where there is a complete list of all ratified extensions. Somewhat equivalently the RVA22 S and U profiles, by requirement, list and categorize all S and

By Greg Favor · #1798 ·

41 - 60 of 1857

Home Hashtags Subgroups Terms