tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Re: Proposal for "Multiple LR/SC forward progress guarantee levels."

Guo, As the guy who probably worked the hardest to get the forward progress guarantees for LR/SC significantly weakened in the RISC-V ISA, I feel I’m going to have to comment here. I’ll

By striker@... · #1237 ·

Proposal for "Multiple LR/SC forward progress guarantee levels."

Abstract Atomic Forward Guarantee is required in many OS to touch contended variables. Linux queued-spinlock is the atomic forward guarantee user who solves the fairness and cache-line bouncing

By Guo Ren · #1236 · Edited

Re: Fast-track extension proposal for "Multiple LR/SC forward progress guarantee levels."

Thx for reminding me, I would resend it with a proper title. -- Best Regards Guo Ren

By Guo Ren · #1235 ·

Re: Fast-track extension proposal for "Multiple LR/SC forward progress guarantee levels."

This proposal is not appropriate for the fast track, on the basis that it’s far from uncontroversial. It should be discussed at length first.

By andrew@... · #1234 ·

Re: Definition of leaf PTE

OK. That was the assumption I have had the whole time, until I started digging deeper recently. Thanks, -Paul

By Paul Donahue · #1232 ·

Re: Definition of leaf PTE

It's clear from context that the spec intends that SFENCE.VMA with rs1 != x0 be sufficient to purge an invalid PTE from an address-translation cache. (And the alternative of requiring SFENCE.VMA with

By andrew@... · #1231 ·

Definition of leaf PTE

The priv spec says that a leaf PTE can be at any level of the walk. If you get to step 5 in the "Virtual Address Translation Process" then you've found a leaf PTE. However, if pte.v=0 then you

By Paul Donahue · #1230 ·

Re: Question about mideleg

Agree Scott. There really is no sip register. sip is mip & mideleg. Jeff

By Jeff Scott · #1229 ·

Re: Question about mideleg

You seem to be confused by the names of the two interrupts MTI and STI. Think of them not as Machine/Supervisor but as Timer Interrupts A and B. One of the two is traditionally delegated to S-mode via

By Scott Johnson · #1228 ·

Re: Question about mideleg

Hmm, I misread that, and re-reading: this implies that sip.MTIP is not necessarily 0. I thought it had to be zero because everything Mmode related is normally hidden from S-mode for virtualization

By Allen Baum · #1227 ·

Re: Question about mideleg

Allen, If you delegate mtip, and you get a mtip, bit 7 in sip will be set, as well as bit 7 in mip. I agree that the non-normative note does not match what is shown in 4.6. This has been

By Jeff Scott · #1226 ·

Re: Question about mideleg

> That problem will go away if the STIMER extension is ratified, I think. Do you mean Sstc (which introduces stimecmp and vstimecmp)? That was ratified last year (though the spec looks like it still

By Paul Donahue · #1225 ·

Re: Question about mideleg

The non-normative note below figure 4.6 and 4.7 say that –but they don’t show that! There is (currently) only one timer signal coming in. If MTIP is delegated without STIP being set (Mmode

By Allen Baum · #1224 ·

Re: Question about mideleg

Also from the spec: “Bits 3, 7, and 11 of sip and sie correspond to the machine-mode software, timer, and external interrupts, respectively. Sincemost platforms will choose not to make these

By Jeff Scott · #1223 ·

Re: Question about mideleg

The question was about delegating MTIP, not STIP. I don’t know why you’re talking about STIP at all; that’s a different interrupt entirely. MTIP vs STIP has nothing to do with what privilege

By Scott Johnson · #1222 ·

Re: Question about mideleg

Allen, I don’t agree that a machine mode interrupt (MEI, MSI, MTI) delegated to supervisor mode shows up in SIP as the supervisor version (SEI, SSI, STI) and not the machine version (MEI, MSI,

By Jeff Scott · #1221 ·

Re: Question about mideleg

mtimecmp is not a CSR: "Platforms provide a 64-bit memory-mapped machine-mode timer compare register (mtimecmp)." It's also not defined to be M-only, though I would assume that M-mode software would

By Paul Donahue · #1220 ·

Re: Question about mideleg

I was looking figure 4.6 of the priv spec, and it does show STIP as bit 5, not bit 7. Bit 7 is MTIP, and it is invisible to Smode. That's why the interrupt pending bit shows up in bit 5 if delegated,

By Allen Baum · #1219 ·

Re: Question about mideleg

Comments embedded: I suspect all implementations disallow it, by forcing those bits in mideleg to 0. OpenSBI does not attempt to delegate those interrupts.[1] How so? I would expect it to show up in

By Scott Johnson · #1218 ·

Re: Question about mideleg

As far as I can tell, an implementation may, but is not required to, disallow it. If it is delegated, it shows up in the SIP. STIP bit But, if it is delegated, then it can only be cleared by an

By Allen Baum · #1217 ·

101 - 120 of 1334

Home Hashtags Subgroups Terms