Vedvyas Shanbhogue wrote: No, neither of those things. - John Hauser

Hi All - Please help with this question on slide 6. Is the intent to define a new MSI data format to cause SW interrupts to be delivered through writes to the seteipnum* register or is the direction

Hi All, Highlights from today's meeting are: 1) Two minor changes in AIA spec 2) Few changes in ACLINT related to MTIMER and SSWI devices 3) Made good progress on AIA Software Phase2 efforts Here's

The mess is in breaking down MTIMER device into two devices MTIME and MTIMECMP. Anyway, I have updated ACLINT draft spec with following changes: A MTIMER device has two separate base addresses:

I don't think there's any mess being requested. One HW constraint with the current proposal, IIUC, is that MTIME register addresses have a fixed relationship to a given set of MTIMECMP registers. Is

Earlier I wrote: Since there seemed to be consensus for this plan (or begrudging acceptance), I've updated the AIA document: https://github.com/riscv/riscv-aia Look under "Releases" for the latest

Siqi Zhao wrote: So the contents of CSRs can be nondestructively examined for debugging. Side effects may still occur on writes. You can see much of the discussion

Not about AIA itself, but what is the reason behind this decision on no side-effect?

I agree, a warning would be wise. The suggestion to leave the *topei CSRs read-only and use *clreipnum would be fine, except for a couple of things: First, because many users are extremely sensitive

That would be a pretty bad software bug by a programmer - that's going to result in flaky system operation. One of many bugs that a programmer could avail himself of. And one reflecting a poor

Hi Greg, Please see inline below … Regards, Anup From: Greg Favor <gfavor@...> Date: Friday, 23 July 2021 at 10:17 AM To: Anup Patel <Anup.Patel@...> Cc: John Hauser <jh.riscv@...>,

Keep in mind that this is effectively the same functionality and semantics as the "old" *claimei CSRs - just slightly changed and renamed. And with exactly the same intent and usage model. In other

Hi John, Please see inline below... Regards, Anup On 23/07/21, 6:43 AM, "John Hauser" <jh.riscv@...> wrote: The guardians of the RISC-V spec have recently decided that standard

The guardians of the RISC-V spec have recently decided that standard RISC-V CSRs will not be defined to have side effects on reads. The AIA currently defines CSRs mclaimei and sclaimei to be

Thanks John. I have noted a few comments below. Yes, the AiA specification already assumes and supports use of hart local interrupts. So section 9.3.5 provides a recipe for the hypervisor to deal

Typo correction in last statement: “[Anup] SOFTWARE can easily adapt to both above approaches without creating a MESS.” From: <tech-aia@...> on behalf of Anup Patel <anup.patel@...> Date:

Please see my response inline below … Regards, Anup From: Josh Scheid <jscheid@...> Date: Tuesday, 20 July 2021 at 2:17 AM To: Anup Patel <Anup.Patel@...> Cc: "tech-aia@..."

And also that those are separate system addresses, or not? That every MTIMECMP group has a "local" MTIME register, which is then designated as aliased or reference? Why do aliased MTIME registers

Lastly, before I shut up, ... A key point in all this is that memory-mapped registers like MTIME/MTIMECMP will be very uncommon. Most registers, even if logically defined as 64 bits wide, can be

In essence, is RV64 going to effectively outlaw ready use of common 32-bit "utility" AMBA bus standards in RV64 systems (especially since there will be a growing number of 64-bit memory-mapped