Encoding:

Format:

DVP rt

Purpose:

Disable Virtual Processor

To disable all virtual processors in a physical core other than the virtual processor that issued the instruction.

Description:

GPR[rt] = VPControl ; VPControlDIS = 1

Disabling a virtual processor means that instruction fetch is terminated, and all outstanding instructions for the affected virtual processor(s) must be complete before the DVP itself is allowed to retire. Any outstanding events such as hardware instruction or data prefetch, or page-table walks must also be terminated.

The DVP instruction has implicit SYNC(stype=0) semantics but with respect to the other virtual processors in the physical core.

After all other virtual processors have been disabled, VPControl_DIS is set. Prior to modification and if rt is nonzero, sign-extended VPControl is written to GPR[rt].If DVP is specified without rt, then rt must be 0.

DVP may also take effect on a virtual processor that has executed a WAIT or a PAUSE instruction. If a virtual processor has executed a WAIT instruction, then it cannot resume execution on an interrupt until an EVP has been executed.

If the EVP is executed before the interrupt arrives, then the virtual processor resumes in a state as if the DVP had not been executed, that is, it waits for the interrupt.

If a virtual processor has executed a PAUSE instruction, then it cannot resume execution until an EVP has been executed, even if LLbit is cleared. If an EVP is executed before the LLbit is cleared, then the virtual processor resumes in a state as if the DVP has not been executed, that is, it waits for the LLbit to clear.

The execution of a DVP must be followed by the execution of an EVP. The execution of an EVP causes execution to resume immediately-where applicable-on all other virtual processors, as if the DVP had not been executed. The execution is completely restorable after the EVP. If an event occurs in between the DVP and EVP that renders state of the virtual processor UNPREDICTABLE (such as power-gating), then the effect of EVP is UNPREDICTABLE.

DVP may only take effect if VPControl_DIS=0. Otherwise it is treated as a NOP instruction.

If a virtual processor is disabled due to a DVP, then interrupts are also disabled for the virtual processor, that is, logically StatusIE=0. StatusIE for the target virtual processors though is not cleared though as software cannot access state on the virtual processors that have been disabled. Similarly, deferred exceptions will not cause a disabled virtual processor to be re-enabled for execution, at least until execution is re-enabled by the EVP instruction. The virtual processor that executes the DVP, however, continues to be interruptible.

In an implementation, the ability of a virtual processor to execute instructions may also be under control external to the physical core which contains the virtual processor. If disabled by DVP, a virtual processor must not resume fetch in response to the assertion of this external signal to enable fetch. Conversely, if fetch is disabled by such external control, then execution of EVP will not cause fetch to resume at a target virtual processor for which the control is deasserted.

This instruction never executes speculatively. It must be the oldest unretired instruction to take effect.

This instruction is only available in Release 6 implementations. For implementations that do not support multithreading (Config5VP=0), this instruction must be treated as a NOP instruction.

Restrictions:

If access to Coprocessor 0 is not enabled, a Coprocessor Unusable Exception is signaled.

In implementations prior to Release 6 of the architecture, this instruction resulted in a Reserved Instruction exception.

Operation:

The pseudo-code below assumes that the DVP is executed by virtual processor 0, while the target virtual processor is numbered 'n', where n is each of all remaining virtual processors.

          
         if (VPControlDIS = 0)
         // Pseudo-code in italics provides recommended action wrt other VPs 
         disable_fetch(VPn) {
             if PAUSE(VPn) retires prior or at disable event
             then VPn execution is not resumed if LLbit is cleared prior to EVP
         }
         disable_interrupt(VPn) {
             if WAIT(VPn) retires prior or at disable event
             then interrupts are ignored by VPn until EVP
         }
         // DVP0 not retired until instructions for VPn completed
         while (VPn outstanding instruction)
             DVP0 unretired
         endwhile
         endif
data = VPControl
GPR[rt] = sign_extend(data)
VPControlDIS = 1

Exceptions:

Coprocessor Unusable

Reserved Instruction (pre-Release 6 implementations)

Programming Notes:

DVP may disable execution in the target virtual processor regardless of the operating mode - kernel, supervisor, user.

Kernel software may also be in a critical region, or in a high-priority interrupt handler when the disable occurs. Since the instruction is itself privileged, such events are considered acceptable.

Before executing an EVP in a DVP/EVP pair, software should first read VPControl_DIS, returned by DVP, to determine whether the virtual processors are already disabled. If so, the DVP/EVP sequence should be abandoned. This step allows software to safely nest DVP/EVP pairs.

Privileged software may use DVP/EVP to disable virtual processors on a core, such as for the purpose of doing a cache flush without interference from other processes in a system with multiple virtual processors or physical cores.

DVP (and EVP) may be used in other cases such as for power-savings or changing state that is applicable to all virtual processors in a core, such as virtual processor scheduling priority, as described below:

   ll t0 0(a0)
   dvp   // disable all other virtual processors
   pause  // wait for LLbit to clear
   evp   // enable all othe virtual processors
   ll t0 0(a0)
   dvp   // disable all other virtual processors
   <change core-wide state>
   evp   // enable all othe virtual processors