Derek, Thx for sharing the presentation with us; I spent some time chewing. So the reply is late. --- The problems of qspinlock --- The Linux queued-spinlock utilizes the lock_pending and

For the record, plenty of big-iron SGI machines also survived the MIPS ISA's LL/SC without stronger forward progress guarantees. The following observation is apparent from Derek's presentation, but I

Oscar Jupp wrote: The caption on Table 7.1 says: The effects of hideleg and hvien on vsip and vsie for major interrupts 13-63. Bits 10, 6, and 2 in vsip are major interrupts 10, 6, and 2

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

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

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

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.

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

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

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

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

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

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

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

> 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

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

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

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

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,

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