tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Re: [RISC-V] [tech-unixplatformspec] RISC-V H-extension plus RISC-V AIA proof-of-concept completed

let's create a top sheet and add this please. philipp is working on a review proposal. likely more like tech-announce for 2 weeks and notify TSC and the board. etc Get BlueMail for Android On Aug 26,

By mark · #834 ·

RISC-V H-extension plus RISC-V AIA proof-of-concept completed

Hi All, The KVM RISC-V AIA support has been successfully validated with AIA IMSIC virtualization features emulated by QEMU RISC-V. This means KVM RISC-V Guest Linux works perfectly fine with

By Anup Patel · #833 ·

Re: [RFC] Toolchain interface for privilege spec related stuff.

Hi Allen: Thanks for the information :) For non-priverage extension, toolchain can control version for each extension by ISA string, e.g. -march=rv64gcv0p10 to specify vector extension with version

By Kito Cheng · #832 ·

Re: [RFC] Toolchain interface for privilege spec related stuff.

Hi Mark: It sounds like we can expect all privilege stuff like machine-level ISA, supervisor ISA will become several extensions at privilege spec 1.12, and then those extensions can be controlled by

By Kito Cheng · #831 ·

Re: [RFC] Toolchain interface for privilege spec related stuff.

.Note that the Imperas OVPsim simulator, and the tests they've written for it, can already specify priv spec version numbers (and vector spec version numbers).

By Allen Baum · #830 ·

Re: [RFC] Toolchain interface for privilege spec related stuff.

+Philipp Tomsich

By mark · #829 ·

Re: [RFC] Toolchain interface for privilege spec related stuff.

all the specs will have unique extension names. it is also possible to have rollup extension names like we have for crypto like Zk. I suggest we make the options match the extension names and if

By mark · #828 ·

[RFC] Toolchain interface for privilege spec related stuff.

Hi : I am Kito Cheng, one of the RISC-V open source toolchain developer. Recently RISC-V LLVM and RISC-V GNU toolchain community are discussing how to version control the privilege spec stuff - which

By Kito Cheng · #827 ·

Re: Effective address width when S mode and U mode has different XLEN

That's true. Regardless of fetching instructions or data, using virtual addresses is always a critical path. It is not good to add any additional logic to this path. But this is the most friendly

By Chang Liu · #826 ·

Re: Effective address width when S mode and U mode has different XLEN

That's right.

By andrew@... · #825 ·

Re: Effective address width when S mode and U mode has different XLEN

Not sure that was the intention. But someone with more authority may be able to shed some light. IIUC the SV39 address space is shared between S-mode and U-mode. Effectively this would mean the top

By Xinhao (Freddie) Qu · #824 ·

Re: Effective address width when S mode and U mode has different XLEN

I believe the two text are complementary. The first is saying what value is stored in the destination register - e.g. pc and rd by JALR - this is the sign extended value. The second text is what is

By Ved Shanbhogue · #823 ·

Re: Effective address width when S mode and U mode has different XLEN

Oops, have we found a contradiction in the spec? If we sign-extend the 32-bit PC 0x80000000 as described in the Machine-level ISA, then the 64-bit VA will not be in the "lowest 4GiB of the address

By Xinhao (Freddie) Qu · #822 ·

Re: Effective address width when S mode and U mode has different XLEN

Specifically for UXLEN which was the op, section 4.1.1.1 provides this guidance on effective address: "If UXLEN < SXLEN, user-mode instruction-fetch addresses and load and store effective addresses

By Ved Shanbhogue · #821 ·

Re: Effective address width when S mode and U mode has different XLEN

Yes, you’re right. Either option will depend on how the hardware extends the address. I assumed zero-extending it would be the default way, but that isn’t the case. In fact, the spec have

By Xinhao (Freddie) Qu · #820 ·

Re: Effective address width when S mode and U mode has different XLEN

This will affect the hardware design: when the processor generates a instruction or data fetch request in U mode (XLEN 32) , how to extend the MSBs of the virtual address. For example, when U mode

By Chang Liu · #819 ·

Re: Effective address width when S mode and U mode has different XLEN

Is this an ISA thing or can this be resolved at the OS level? Unless I’m missing anything, it feels that option 2 is the easiest as it won’t need any hardware change. Regards, Freddie

By Xinhao (Freddie) Qu · #818 ·

Effective address width when S mode and U mode has different XLEN

In a system using SV-39, RISC-V privileged spec defines the behavior of address calculation and page fault detection: Instruction fetch addresses and load and store effective addresses, which are 64

By Chang Liu · #817 ·

Re: Hypervisor exception priorities

So a special case occurs for setting A or D bits in first stage PTE where a second level leaf PTE may cause a page fault before and after providing the translation to the first stage. Walk to find

By Ved Shanbhogue · #816 ·

Re: Hypervisor exception priorities

I haven't double-checked myself, but I believe this mixed priority between PF and GPF exceptions is resolved by the fact that the Priv spec spells out the logical sequence of steps to translate an

By Greg Favor · #815 ·

501 - 520 of 1333

Home Hashtags Subgroups Terms