Assembly:

DVP rt

Purpose:

Disable Virtual Processors. Disable all virtual processors in a physical core other than theone that issued the instruction. Set VPControl.DIS to 1, and place the previous value of the VPControl CP0 register in register $rt.

Availability:

nanoMIPS. Optional, present when Config5.VP=1, otherwise NOP. Requires CP0 privilege.

Format:

Operation:

if C0.Config5.VP == 0:
    # No operation when VP not implemented pass
else:
    if not IsCoprocessor0Enabled():
        raise coprocessor_exception(0)
    GPR[rt] = C0.VPControl
    C0.VPControl.DIS = 1
    disable_virtual_processors()

The DVP instruction is used to halt instruction fetch for all virtual processors in a VP core, other than the one which issued the DVP instruction. Possible uses for DVP include:

• Performing cache operations where the cache state must not be affected by the actions of other

threads on the same core.

• Reprogramming virtual processor scheduling priority.

All outstanding instructions for the affected virtual processors 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.

Memory ordering equivalent to that provided by SYNC(stype=0) is guaranteed between subsequent

instructions on the virtual processor which issued the DVP, and instructions which have already graduated on the disabled virtual processors.

If a virtual processor is already disabled by another event,for instance,if it has executed a WAIT or a PAUSE instruction or has been halted by some external hardware event,then the disabled virtual

processor will not be re-enabled until both an EVP instruction has been executed on the controlling thread, and an event which would otherwise have woken the virtual processor (such as an interrupt for

a WAIT instruction or an interrupt or clearing of the LLBit for a PAUSE instruction) has also occurred.

The effect of a DVP instruction is undone by an EVP instruction, which causes execution to resume immediately (where applicable) on all other virtual processors. From the perspective of the disabled

virtual processors, after the EVP, execution continues as though the DVP had not occurred.

If an event occurs in between the DVP and EVP that renders state of a disabled virtual processor UNPREDICTABLE (such as power-gating), then the effect of EVP is UNPREDICTABLE.

A disabled virtual processor cannot be woken by an interrupt or a deferred exception, at least until execution is re-enabled by an EVP instruction on the controlling thread.The virtual processor that

executes the DVP, however, continues to be interruptible.

A DVP which is executed when VPControl.DIS=1 will return the current value of the VPControl register but otherwise will leave the other virtual processors in a disabled state. Software should only re-enable

virtual processors (via the EVP instruction) if it has verified from the VPControl value returned by the DVP that virtual processors were previously enabled. Performing this check allows DVP/EVP pairs to

be safely nested.

In a core with multiple virtual processors, more than one virtual processor may execute a DVP simultaneously. The implementation should ensure that the selection of which virtual processor’s DVP successfully graduates is not biased towards any one virtual processor, in order to prevent the possibility

of live-lock.

The DVP instruction behaves like a NOP on cores which do not implement virtual processors (i.e. when Config5.VP=0). This behavior allows kernel code to enclose critical sequences within DVP/EVP blocks

without first checking whether itis running on a VP core.The encoding ofthe DVP instruction is equivalentto a SLTU instruction targeting $0,i.e.a NOP, which leads to the correct behavior on

non-VP cores with no additional hardware special casing.

Exceptions:

Coprocessor Unusable.