tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Re: 32-bit accesses to mtime/mtimecmp under RV64

more mtimecmp questions: - the spec says that an interrupt occurs is posted when the mtime register contains a value greater than or equal to the value inthe mtimecmp register. but doesn't

By Allen Baum · #94 ·

Re: 32-bit accesses to mtime/mtimecmp under RV64

To widen the question slightly further are there any plans to provide atomic load/store pair operations (128-bits for RV64, 64-bits for RV32)?

By Mark Hill · #93 ·

Re: 32-bit accesses to mtime/mtimecmp under RV64

I think your interpretation of that sentence is accurate. FWIW, the insufficiently described Linux platform does assume such accesses are legal (more precisely, the various SBI implementations make

By andrew@... · #92 ·

Re: 32-bit accesses to mtime/mtimecmp under RV64

So the only constraint is that when a 64b naturally-aligned access is made to mtime/mtimecmp, the access must be completed atomically if the platform allows 64b naturally-aligned accesses to those

By David Kruckemyer · #91 ·

Re: 32-bit accesses to mtime/mtimecmp under RV64

The second half of my answer was addressing the more general matter. For mtime and mtimecmp specifically, the spec is now clear:

By andrew@... · #90 ·

Re: 32-bit accesses to mtime/mtimecmp under RV64

Asking this slightly differently (I think) to clarify.... With respect to mtime/mtimecmp, does an RV64 processor place constraints on the platform, or can the platform place constraints on the RV64

By David Kruckemyer · #89 ·

Re: 32-bit accesses to mtime/mtimecmp under RV64

The spec strongly implies by omission that 64-bit accesses are atomic for RV64, in that it gives an unusually detailed RV32-specific code example to cope with non-atomicity, but mentions nothing of

By andrew@... · #88 ·

32-bit accesses to mtime/mtimecmp under RV64

The mtime and mtimecmp registers are defined as 64-bit memory-mapped registers. The priv spec says that - in RV32 - mtimecmp can be written as a pair of 32-bit registers. Since this was made

By Greg Favor · #87 ·

Re: Handling faults on new HLV/HSV instructions in Hypervisor Extension draft 0.6

By Anup Patel · #86 ·

Re: Handling faults on new HLV/HSV instructions in Hypervisor Extension draft 0.6

John, thanks for the full responses. I had suspected the former. But as can sometimes be the case, we were looking at certain parts of the spec and weren't looking at the tables in section

By Greg Favor · #85 ·

Re: Handling faults on new HLV/HSV instructions in Hypervisor Extension draft 0.6

Having SPP/SPV hold the real values makes the most sense to me. The strategy I'd expect hypervisors to use would be to set a bit before issuing any HLV or HSV instructions and clear it after. Then in

By Jonathan Behrens <behrensj@...> · #84 ·

Re: Handling faults on new HLV/HSV instructions in Hypervisor Extension draft 0.6

Greg Favor wrote: The actual virtualization and privilege modes, same as always. Consider the analogy with memory accesses made in M mode when mstatus.MPRV = 1. The document says that such memory

By John Hauser · #83 ·

Handling faults on new HLV/HSV instructions in Hypervisor Extension draft 0.6

When one of the new HLV/HSV instructions faults, what virtualization and privilege modes are recorded in mstatus.mpp/mpv, or in sstatus.spp/spv and hstatus.spvp? Are they based on the actual modes

By Greg Favor · #82 ·

Re: Proposal for accelerating nested virtualization on RISC-V

Hi Jonathan, All cases for CSR accesses have not been thought through (initial draft) and written out. Regarding WARL CSR with hardwired bits, the HW will always read/write fixed values of

By Anup Patel · #81 ·

Re: Proposal for accelerating nested virtualization on RISC-V

Your description of un-accelerated nested virtualization seems workable to me. I'm less sure of the proposal to avoid trapping on h<xyz> and vs<xyz> accesses. Aren't you going to run into issues with

By Jonathan Behrens <behrensj@...> · #80 ·

Proposal for accelerating nested virtualization on RISC-V

A clarification is required in RISC-V H-Extension spec regarding scope of HSTATUS.VTVM bit. Currently as-per the spec, all virtual memory management instructions (both SFENCEs and HFENCEs) will trap

By Anup Patel · #79 ·

Re: [tech-privileged] hypervisor extension: seL4 experience and feedback

As Andy already pointed out, the RDINSTRET could be quite useful for other purposes as well (e.g., record-and-reply or redundant execution). Would it be possible to add a filter or mask so that

By Andy Glew Si5 · #78 ·

Re: [tech-privileged] hypervisor extension: seL4 experience and feedback

Hi John, See my responses inline below. Regards, Yanyan Thanks very much for your installments, which clarify things and help us to understand the extension. So, it is expected that the

By Shen, Yanyan (Data61, Kensington NSW) <yanyan.shen@...> · #77 ·

Re: Huawei review of different PMP enhancement schemes

Nick Kossifidis wrote: All of the other proposals, including the one you favor, have this exact same property when MML = 0. As I wrote in my document, and have tried repeatedly to make clear, the

By John Hauser · #76 ·

Re: [RISC-V] [tech-tee] Huawei review of different PMP enhancement schemes

Στις 2020-02-28 21:14, John Hauser έγραψε: You've excluded the possibility of having a region that's writeable by S/U and executable by M mode at the same time. However it's possible for S/U

By mick@... · #75 ·

1241 - 1260 of 1334

Home Hashtags Subgroups Terms