tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Siqi (zhaosiqi3@...) wrote: Also, sorry, failed to notice you said vsip, not hip. The previous draft of the hypervisor extension, 0.5, never allowed writing directly to vsip from VS mode,

By John Hauser · #114 ·

Re: Question on the new hvip register

Siqi (zhaosiqi3@...) wrote: The same question was raised not long ago on the RISC-V ISA Dev mailing list. The following is clipped from that conversation. -------------------- Jose Martins

By John Hauser · #113 ·

Question on the new hvip register

Hi, Reading through the hypervisor extension v0.6, I noticed the new register called hvip. The spec says that this register is intended for the hypervisor to write to indicate pending interrupts

By Siqi Zhao · #112 ·

Microarchitectural state flush for timing-channel prevention

Dear Privspec members, You may recall that I had argued for an operation to flush microarchitectural state in order to allow the OS to prevent timing channels. I believe the need for this was not

By Gernot <gernot.heiser@...> · #111 ·

Re: hstatus.VTW for WFI

Paolo Bonzini wrote: Okay, I get it now. You're proposing we bring back hstatus.VTW, the HS-mode analog to mstatus.TW. (We had the VTW bit originally in hstatus, but dropped it long ago.) Anyone

By John Hauser · #110 ·

Re: proposal to add "virtual instruction exception" to the hypervisor extension

But this would be a VS-mode application, not an ordinary user-mode application. I'm not sure why U-mode matters. Anyway... ... I guess this is the misunderstanding. I'm not proposing to

By Paolo Bonzini · #109 ·

Re: proposal to add "virtual instruction exception" to the hypervisor extension

Paolo Bonzini wrote: I'm afraid this makes no sense to me. Ordinary user-mode applications don't execute WFI. In U mode, WFI is useful only in connection with support for user-level interrupts

By John Hauser · #108 ·

Re: proposal to add "virtual instruction exception" to the hypervisor extension

By Anup Patel · #107 ·

Re: proposal to add "virtual instruction exception" to the hypervisor extension

It would be great to have this controlled by a bit in the hstatus CSR. For example a hypervisor that does not overcommit CPUs will probably want to delegate WFI to the guest. Guest-delegated

By Paolo Bonzini · #106 ·

Re: proposal to add "virtual instruction exception" to the hypervisor extension

It mostly just comes down to crossing out "In VS-mode" in your list of cases for trapping when V=1: - attempts to execute an HFENCE instruction or to access an implemented hypervisor CSR or VS

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

Re: proposal to add "virtual instruction exception" to the hypervisor extension

Jonathan Behrens wrote: Point taken. Would you like to take a stab at listing every case you think should be included, besides HFENCE? - John Hauser

By John Hauser · #104 ·

Re: proposal to add "virtual instruction exception" to the hypervisor extension

I like this plan. The one comment I have is that it seems unnecessarily opinionated about which operations trigger virtual instruction traps vs illegal instruction traps when run in VU mode. I think

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

proposal to add "virtual instruction exception" to the hypervisor extension

Hello tech-privileged guys, I've created a pull request for the RISC-V privileged spec in response to requests from our hypervisor software

By John Hauser · #102 ·

RISC-V Hypervisor Updates

Hi All, We have updated QEMU RISC-V, KVM RISC-V and Xvisor RISC-V for RISC-V H-Extension v0.6 spec. The QEMU repo with RISC-V H-Extension v0.6 support can be found

By Anup Patel · #101 ·

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

Ah..... yeah, ok. that "atoimc" (single-copy atomicity) vs the "atomic" (LR/SC pair). My bad. Apologies Mark (assuming Andy is right and you meant load and store instructions that are

By striker@... · #100 ·

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

I assumed that Dr Mark Hill was talking about 256 bit atomic loads and stores to ask the FIFO, not LR/SC. Also, double width CAS (and other double width atomics) is used not just for A-B-A

By Andy Glew Si5 · #99 ·

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

Interesting. If you had a H/W FIFO, seems like it would be easier to make it work with single-copy atomic loads or stores to read from or write to the FIFO rather than bothering with the tedium of

By striker@... · #98 ·

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

Another possible use case is access sensitive devices, for example a FIFO of 128-bit records with multiple RV64 harts reading from the FIFO.

By Mark Hill · #97 ·

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

Just for you, Allen. https://github.com/riscv/riscv-isa-manual/commit/a1c7d2553cb6fba3d8636355e2a7cb247d047d7c

By andrew@... · #96 ·

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

To widen your question even further Mark (no pun intended), do we need 256 bits for RV128? Yes, RV128 is a bit speculative, but it does at least rate being in the book, so best to have all the

By striker@... · #95 ·

1221 - 1240 of 1334

Home Hashtags Subgroups Terms