WO2015061554A1

WO2015061554A1 - Method and apparatus for performing a bus lock and translation lookaside buffer invalidation

Info

Publication number: WO2015061554A1
Application number: PCT/US2014/061944
Authority: WO
Inventors: William L. Walker; Paul J. Moyer; Richard M. Born; Eric Morton; David Christie; Marius Evers; Scott T. BINGHAM
Original assignee: Advanced Micro Devices, Inc.
Priority date: 2013-10-25
Filing date: 2014-10-23
Publication date: 2015-04-30
Also published as: US20150120976A1; JP2016534432A; CN105765547A; JP6609552B2; EP3060996A4; EP3060996A1; KR20160075638A; US9916243B2; KR102165775B1

Abstract

A method and apparatus for performing a bus lock and a translation lookaside buffer invalidate transaction includes receiving, by a lock master, a lock request from a first processor in a system. The lock master sends a quiesce request to all processors in the system, and upon receipt of the quiesce request from the lock master, all processors cease issuing any new transactions and issue a quiesce granted transaction. Upon receipt of the quiesce granted transactions from all processors, the lock master issues a lock granted message that includes an identifier of the first processor. The first processor performs an atomic transaction sequence and sends a first lock release message to the lock master upon completion of the atomic transaction sequence. The lock master sends a second lock release message to all processors upon receiving the first lock release message from the first processor.

Description

METHOD AND APPARATUS FOR PERFORMING A BUS LOCK AND TRANSLATION LOOKASIDE BUFFER INVALIDATION

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent

Application No. 61/895,569 filed October 25, 2013, the contents of which are hereby incorporated by reference herein.

FIELD OF THE INVENTION

[0002] The present invention is generally directed to bus lock operation and translation lookaside buffer invalidation operation.

BACKGROUND

[0003] Multiprocessor systems use atomic read- modify- write operations to process shared data structures amongst multiple processors or threads. These may operate on cacheable memory, as well as on noncacheable memory. When the operation is to cacheable memory and does not cross a boundary, (e.g., a cache line), the processor may utilize internal means such as cache line locking to keep the operation atomic. When the bus lock is to non-cacheable memory, or crosses a boundary where the processor cannot use an internal means, it requires a way to perform an atomic read-modify-write.

[0004] A common solution to provide the necessary atomicity for noncacheable atomic transactions is to "lock" the interconnect fabric, (i.e., the wiring and the signaling protocols by which processors, caches, and memory communicate with each other), reserving sole use of it to the one processor and stalling all others. Conventionally, this has been done in the fabric by arbitrating for, and enforcing, the lock condition at each switch point in the topology of the fabric.

[0005] Additionally, processors use virtual-to-physical address translation schemes and commonly cache these operations in Translation Lookaside Buffers (TLBs). When software changes one of these translations, such as to invalidate a virtual address, change protections on a page, move a page and the like, all cached (TLB) copies of the translations have to be removed before the software can take the changed translation into effect.

[0006] One conventional solution used to synchronize changes to translations is to let software explicitly invalidate TLBs on multiple processors by interrupting all processors and running a task on each one to invalidate the TLB entry, or entries, that changed. The processor initiating the translation change interrupts every other processor. The receiving processors run an interrupt handler that flushes the changing translation from their TLBs. Another conventional method used to synchronize changes to translations is direct hardware communication from processor to processor, (e.g., the software uses explicit TLB invalidate instructions to send hardware messages to every other processor describing the translation that is changing). After one or more initiating processors sends a "synchronize" message to every other processor and receives a handshake response back when all prior TLB-invalidate messages have had their full effect at that processor. Dedicated hardware ensures that the synchronize operation will not finish until every processor has stopped using every translation that was invalidated before the synchronization operation began.

[0007] In the conventional bus lock solution, every intermediate switch point in the interconnect fabric must be aware of the lock and implement hardware for it. Each switch point arbitrates between competing lock requestors and each switch point enforces a granted lock by interdicting traffic from non- locked processors. Accordingly, larger systems require more complex interconnect topologies.

[0008] The conventional synchronization solution for TLB invalidation requires point to point communication. This solution may not scale up well because it requires wiring or transactions proportional to the square of the number of processors involved. Additionally, it may result in lower performance through serialization of invalidate/sync sequences issued by multiple processors at the same time. [0009] It would therefore be beneficial to provide a method and apparatus for performing a bus lock and/or a TLB invalidation that is not subject to the limitations of the conventional solutions.

SUMMARY OF EMBODIMENTS

[0010] An embodiment directed to a method for performing a bus lock is disclosed. The method includes receiving, by a lock master, a lock request from a first processor in a system. The lock master sends a quiesce request to all processors in the system, and upon receipt of the quiesce request from the lock master, all processors cease issuing any new transactions and issue a quiesce granted transaction. Upon receipt of the quiesce granted transactions from all processors, the lock master issues a lock granted message that includes an identifier of the first processor. The first processor performs an atomic transaction sequence and sends a first lock release message to the lock master upon completion of the atomic transaction sequence. The lock master sends a second lock release message to all processors upon receiving the first lock release message from the first processor.

[0011] An embodiment directed to a system for performing a bus lock is disclosed. The system includes a plurality of processors and a lock master. The lock master is configured to receive a lock request from a first processor of the plurality of processors in the system and send a quiesce request to all processors in the system. Upon receipt of a quiesce granted transaction from all processors, the lock master issues a lock granted message that includes an identifier of the first processor. The lock master sends a second lock release message to all processors upon receiving a first lock release message from the first processor.

[0012] An embodiment directed to an apparatus for performing a bus lock is disclosed. The apparatus includes circuitry configured to receive a lock request from a first processor of a plurality of processors in a system and send a quiesce request to all processors in the system. Upon receipt of a quiesce granted transaction from all processors, the apparatus issues a lock granted message that includes an identifier of the first processor. The apparatus sends a second lock release message to all processors upon receiving a first lock release message from the first processor.

BRIEF DESCRIPTION OF THE DRAWINGS

[0013] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0014] Figure 1 is a block diagram of an example device in which one or more disclosed embodiments may be implemented;

[0015] Figure 2 is a schematic representation of an example system according to an embodiment;

[0016] Figure 3 is a flow diagram of an example method of performing a bus lock according to an embodiment; and

[0017] Figure 4 is a flow diagram of an example method of performing a translation lookaside buffer (TLB) invalidation according to an embodiment.

DETAILED DESCRIPTION OF THE EMBODIMENTS

[0018] Although a more detailed description of the embodiments is provided below, briefly a central lock master acts as an arbiter to receive requests to lock the bus from a processor when the processor has need to commence an atomic read-modify- write procedure. The lock master controls the bus to ensure that no other processors utilize the bus for any other operation. In another embodiment, a central synch master receives translation lookaside buffer (TLB) invalidate requests from a processor and broadcasts a synch message to all processors in the system.

[0019] Figure 1 is a block diagram of an example device 100 in which one or more disclosed embodiments may be implemented. The device 100 may include a computer, for example, a desktop computer, a tablet computer, a gaming device, a handheld device, a set-top box, a television, or a mobile phone. The device 100 includes a processor 102, a memory 104, a storage 106, one or more input devices

108, and one or more output devices 110. The device 100 may also optionally include an input driver 112 and an output driver 114. It is understood that the device 100 may include additional components not shown in Figure 1.

[0020] The processor 102 may include a central processing unit (CPU), a graphics processing unit (GPU), a CPU and GPU located on the same die, or one or more processor cores, wherein each processor core may be a CPU or a GPU. The memory 104 may be located on the same die as the processor 102, or may be located separately from the processor 102. The memory 104 may include a volatile or non-volatile memory, for example, random access memory (RAM), dynamic RAM, or a cache.

[0021] The storage 106 may include a fixed or removable storage, for example, a hard disk drive, a solid state drive, an optical disk, or a flash drive. The input devices 108 may include a keyboard, a keypad, a touch screen, a touch pad, a detector, a microphone, an accelerometer, a gyroscope, a biometric scanner, or a network connection (e.g., a wireless local area network card for transmission and/or reception of wireless IEEE 802 signals). The output devices 110 may include a display, a speaker, a printer, a haptic feedback device, one or more lights, an antenna, or a network connection (e.g., a wireless local area network card for transmission and/or reception of wireless IEEE 802 signals).

[0022] The input driver 112 communicates with the processor 102 and the input devices 108, and permits the processor 102 to receive input from the input devices 108. The output driver 114 communicates with the processor 102 and the output devices 110, and permits the processor 102 to send output to the output devices 110. It is noted that the input driver 112 and the output driver 114 are optional components, and that the device 100 will operate in the same manner if the input driver 112 and the output driver 114 are not present. Although described embodiments include a main display, the invention may be practiced without a main display, and only include a source device of video. In this way, the control territory may be an office environment with a plurality of portable devices and no main display.

[0023] Figure 2 is a schematic representation of an example system 200 according to an embodiment. The example system 200 includes a plurality of processors 102I-102N, (designated PO-P(N)), a plurality of memory devices 104o- 104M, (designated MemO-Mem(M)), and a lock/synch master 210. As shown in Figure 2, the processors 102 are associated with a respective memory 104 via nodes, or switches, "X", with the lock/synch master 210 connected to a node that is directly connected to the memory 104o, although the lock/synch master 210 may be connected to any node X. In the example system 200, processors P0-P5 are associated with MemO, processors P6-P8 are associated with Meml, and processors P(N-1)-P(N) are associated with Mem(M). It should be noted that although a plurality of memory 104 are shown, any number, and even only one memory may be present in the example system 200. Additionally, although various processors 102 are shown associated with particular memory 104, it should be noted that any processor 102 may have access to any of the memory 102 shown in the example system 200.

[0024] Prior to performing either a bus lock operation or a TLB invalidation, processors send a message to the lock/synch master regarding joining/leaving the active pool of processors. This is done to allow the lock/synch master to know which processors are awake and which are asleep at any given time. For example, a processor may send a message to the lock/synch master when the processor wakes to let the lock master know it has joined the active pool of processors and send a message to the lock master when the processor intends to enter a sleep state so that the lock master knows the processor has left the active pool, and will not expect signaling from that processor.

[0025] Figure 3 is a flow diagram of an example method 300 of performing a bus lock according to an embodiment. For convenience, the lock/synch master is described as a "lock master" for example method 300.

[0026] In step 301, a processor sends a lock request to the lock master when the processor has need to begin an atomic read-modify-write transaction. The lock request travels through the interconnect fabric similar to a noncached write, and includes a value that identifies the requesting processor, (e.g., core). The identifier (ID) may be in the form of a core ID. It should be noted that one or more processors may send a lock request to the lock master substantially simultaneously or in close succession to one another.

[0027] Upon receiving the lock requests from the processors, the lock master queues them and makes a determination regarding which one to process first (step 302). Once the lock master has made its determination, it sends a quiesce request to all processors (step 303). This broadcast quiesce request message travels through the interconnect fabric, similar to a coherence probe, and instructs all processors to cease utilizing the interconnect fabric.

[0028] In step 304, the processors stop issuing new transactions on the interconnect fabric and wait for any outstanding transaction to complete. Once outstanding transactions are complete, the processors issue a quiesce granted transaction on the interconnect fabric to the lock master and wait.

[0029] The lock master counts received quiesce granted transactions from the processors and when the count matches number of the active processors, (i.e., all quiesce granted transactions have been received) in step 305, issues by broadcast a lock granted message (step 306). The lock granted message includes the ID of the processor whose lock is being granted.

[0030] In step 307, each processor receives the lock granted message from the lock master and compares the grant ID to its own ID. If the grant ID is the processor's ID (step 308), then the processor proceeds with its atomic transaction sequence, (e.g., a read-modify-write), and issues a lock release message to the lock master when complete (step 309). If the grant ID does not match the processors ID in step 308, then the processor refrains from using the interconnect fabric (step 312).

[0031] If the lock master has received multiple lock requests (step 310), then the method returns to step 306 where the lock master issues a new lock granted message to the processor that includes the next processors ID grant. Otherwise, the lock master sends a lock release via broadcast message to all the processors (step 311), and the each processor resumes using the interconnect fabric upon receiving the lock release from the lock master. [0032] Figure 4 is a flow diagram of an example method 400 of performing a translation lookaside buffer (TLB) invalidation according to an embodiment. For purposes of convenience, the lock/synch master is referred to as the synch master in the example method 400.

[0033] When a processor needs to change a translation, the processor sends a series of TLB invalidate requests to the synch master, which include the translations that are being deleted (step 401). Then the processor sends a single synch request to the lock master that includes its unique processor ID. To execute the invalidate sequence as quickly as possible, the invalidate requests may be pipelined, whereby the synch request enforces serialization. That is, since serialization requires that a processor changing a translation cannot enable the new translation until it knows that no other processor is still using the old translation, by pipelining invalidate requests, (e.g., issuing a "batch" of any number of TLB invalidate operations followed by a single synchronization operation), the invalidate sequence may be accelerated.

[0034] The synch master broadcasts the invalidate request to all processors

(step 402), and broadcasts a synch message to every processor (step 403). Upon receipt of the invalidate request and synch message, each processor ensures that it has completed using any previously invalidated transactions, and issues a synch complete message to the synch master (step 404).

[0035] The synch master counts the received synch complete messages from the processors and when the count matches number of the active processors, issues by broadcast a synch complete message to the processors (step 405). The synch complete message includes the processor ID whose sync request is completing. If the synch master has multiple synch requests queued, (e.g., it received more than one synch request from more than one processor), but has not received any intervening invalidate requests, the synch master may issue multiple synch complete messages in step 405, instead of individual synch complete messages. This may accelerate the handling of overlapping invalidate/sync sequences by multiple processors. When each processor receives the synch complete message from the synch master, if that processor has not requested a synch then it ignores the synch complete message and continues its normal execution. If that processor has requested a synch, then it compares the ID in the message to its own ID (step 406). If the ID matches in step 406, then the processor knows its own synch has finished (step 407). If the ID does not match, then the processor continues waiting for the synch master to perform the synch that the processor requested. Alternatively, the synch complete message sent by the synch master may be sent only to the processor whose ID is included in the message, or to a subset of the total processors.

[0036] It should be understood that many variations are possible based on the disclosure herein. Although features and elements are described above in particular combinations, each feature or element may be used alone without the other features and elements or in various combinations with or without other features and elements.

[0037] For example, the interconnect fabric may include any of a variety of technologies. It may include wires between components on an integrated circuit die, wiring on an interposer or package substrate between integrated circuit dies sharing a package, or wiring on a printed circuit board between packages.

[0038] Additionally, although the lock master and the synch master are described above as being resident in a single entity, (i.e., 210), it should be noted that they may each reside in separate entities.

[0039] Furthermore, the methods 300 and 400 above may be implemented in the components of the example system 200, where the lock master or synch master includes the lock/synch master 210 and the processors include processor PO-P(N). The read-modify-write operations described above may include the processors in Figure 2 performing a read-modify-write operation to their respective memory, (i.e., MemO-Mem(M)).

[0040] The methods provided may be implemented in a general purpose computer, a processor, or a processor core. Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine. Such processors may be manufactured by configuring a manufacturing process using the results of processed hardware description language (HDL) instructions and other intermediary data including netlists (such instructions capable of being stored on a computer readable media). The results of such processing may be maskworks that are then used in a semiconductor manufacturing process to manufacture a processor which implements aspects of the present invention.

[0041] The methods or flow charts provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable storage medium for execution by a general purpose computer or a processor. Examples of computer-readable storage mediums include a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).

Embodiments:

1. A method of performing a function.

2. The method of embodiment 1 wherein the cache is an L2 or L3 cache.

3. A method as in any preceding embodiment, further comprising a synchronization barrier (DSB) instruction.

4. A method as in any preceding embodiment wherein a synchronization barrier instruction performs a specific synchronization with every core in the coherent domain.

5. A method as in any preceding embodiment, further comprising completing synchronization after every other core stops using any translations affected by any TLBI previously issued by a same thread now using the DSB.

6. A method as in any preceding embodiment wherein a thread issues either a DSB or bus lock. 7. A method as in any preceding embodiment wherein an LS restricts itself to never issue a buslock from both threads.

8. A method as in any preceding embodiment wherein an LS restricts itself to never issues a DSB from both threads.

9. A method as in any preceding embodiment wherein a DSB is issued from one thread and a buslock from a second thread.

10. A method as in any preceding embodiment wherein a DVMOp is a posted write.

11. A method as in any preceding embodiment, further comprising waiting for all pending writes to finish from a thread before issuing a DVMSync request from that thread.

12. A method as in any preceding embodiment wherein waiting for all pending writes to finish from a thread includes any DVMOp requests.

13. A method as in any preceding embodiment wherein once an LS has issued a DVMSync request, it does not issue any TLBI on behalf of that thread until the DVMSync has received its DVMComplete.

14. A method as in any preceding embodiment, further comprising issuing only one DVMSync at a time.

15. A method as in any preceding embodiment wherein a second DVMSync is not issued from the time a DVMSync message is sent to the time a DVMComplete message is sent.

16. A method as in any preceding embodiment wherein multiple DVMSync requests from different threads are collapsed and handled with a single DVMSync/DVM Complete sequence.

17. A method as in any preceding embodiment wherein during a sync, the memory controller continues to process normal requests including bus locks.

18. A method as in any preceding embodiment wherein DVMSync requests are per-thread.

19. A method as in any preceding embodiment wherein DVMComplete requests are percore. 20. A method as in any preceding embodiment wherein a core performs a handshake, via register write, with the memory controller.

21. A method as in any preceding embodiment wherein a core, during CC6 entry, tells the memory controller it is finished using its TLB and shutting down, so the memory controller does not expect any DVMComplete requests from the core anymore.

22. A method as in any preceding embodiment wherein a core, during CC6 exit and during reset, tells the memory controller it is about to start using its TLB, so the memory controller can start expecting DVMComplete requests from the core in response to DVMSync messages.

23. A method as in any preceding embodiment wherein an ITLB sends an internal 2 cycle probe to LS (address + additional fields).

24. A method as in any preceding embodiment wherein a ZVA is 4 WC+ stores guaranteed to be not closed until the cache hierarchy receives all 4 stores.

25. A method as in any preceding embodiment wherein CLFLUSH is a separate transaction command type.

26. A method as in any preceding embodiment wherein performance of strongly ordered OPs with ~LS_L2StWcbReqPosted is limited by a number of WCB L2 buffers.

27. A method as in any preceding embodiment wherein LS_L2StWcbReqPosted is set for weakly ordered transactions.

28. A method as in any preceding embodiment wherein LI is probed only on coherent memtypes and if L2 tags show it is resident in LI.

29. A method as in any preceding embodiment, further comprising an instruction called TLBI that invalidates TLB entries, either locally or globally.

30. A method as in any preceding embodiment wherein a thread sends out a series of TLBI that are pipelined.

31. A method as in any preceding embodiment wherein a bandwidth for TLBI series is one every 5-10 cycles.

32. A method as in any preceding embodiment wherein chained messages in the probe channel are not interleaved. 33. A method as in any preceding embodiment wherein there are normal probes between the chained messages at the SDP port, but XSI hides this type of interleving.

34. A method as in any preceding embodiment whrein only idle cycles are between two DVMOp messages.

35. A method as in any preceding embodiment wherein, during CC6 entry L1I, LID, and L2 are flushed.

36. A method as in any preceding embodiment wherein, during PC6 entry L3 is flushed.

37. A method as in any preceding embodiment wherein software executes execute eight of the new FlushL2Way CMOs.

38. A method as in any preceding embodiment wherein the flush iterator in L3Ctl flushes the L2 and L2 shadow tags, but not the L3.

39. A method as in any preceding embodiment wherein an SMU issues eight SMN writes to L3CTL1 with the FlushL3Way command.

40. A method as in any preceding embodiment wherein an iterator in L3Ctl flushes two ways of the L3 cache.

41. A method as in any preceding embodiment wherein when a flush of an L2 cache location discovers that the line is also present in DC, L2Ctl probes the line out of DC.

42. A method as in any preceding embodiment wherein invalidating IC is the responsibility of the core.

43. A method as in any preceding embodiment, further comprising local and global monitors to support synchronization and semaphores in a multi-core system.

44. A method as in any preceding embodiment wherein each core has a local monitor inside LS, and a global monitor outside the CPU.

45. A method as in any preceding embodiment wherein a local monitor is in or near the coherent slave of the memory controller.

46. A method as in any preceding embodiment wherein an LS applies an

Exclusive transaction property to a noncached load or store transaction. 47. A method as in any preceding embodiment further comprising transmitting a property from LS to the SDF as part of transaction encoding, but not handling the transaction any differently.

48. A method as in any preceding embodiment wherein noncached store responses from SDF may have a property called "ExOkay" indicating the success or failure of the exclusive readmodify- write.

49. A method as in any preceding embodiment wherein a property is transmitted with the response all the way to LS.

50. A method as in any preceding embodiment wherein a CLREX is handled entirely by the local monitor.

51. A method as in any preceding embodiment wherein an NS may pass through as an attribute of all memory requests.

52. A method as in any preceding embodiment wherein an NS is stored in tags.

53. A method as in any preceding embodiment wherein an NS is set as indicated by MCT on a refill response, and reacted to ultimately by LS as it attempts to complete a load or store.

54. A method as in any preceding embodiment wherein , if an executing thread is not in secure state, per the appropriate control register bit in the core (SCR_EL3.NS), and the NS tag bit is clear, it denies the access and raises an exception.

55. A method as in any preceding embodiment wherein necessary semantics for core accesses are included in the core itself.

56. A method as in any preceding embodiment further comprising prefetch instructions including and combination of the following attributes: Access mode: {load, store, instructions (ARM only)}, Cache level: {LI, L2, L3}, and/or Usage: {normal, non-temporal}.

57. A method as in any preceding embodiment wherein an L2 is inclusive of the LI.

58. A method as in any preceding embodiment wherein a prefetch targeting the LI will also target the L2. 59. A method as in any preceding embodiment wherein prefetch support comes from LS or IT.

60. A method as in any preceding embodiment wherein if prefetch support comes from LS, the L2 is loaded.

61. A method as in any preceding embodiment wherein a core can go into an idle low power state pending an interrupt or an event.

62. A method as in any preceding embodiment wherein an event is a generic wakeup that any thread can broadcast to all other threads.

63. A method as in any preceding embodiment wherein interrupts and events both arrive at a core on the interrupt channel.

64. A method as in any preceding embodiment wherein when a thread executes SEV it goes out from LS to L2 as a noncached write to a special address.

65. A method as in any preceding embodiment wherein logic outside a CPU is responsible for recognizing that write and broadcasting the event on the interrupt channel.

66. A method as in any preceding embodiment wherein if both threads in a core are executing WFE or WFI then the core enters CCl (clocks halted).

67. A method as in any preceding embodiment wherein an SCFCTP block in L3I takes care of waking the core when the event or interrupt arrives.

68. A method as in any preceding embodiment wherein interrupt controller with per-thread resources lives outside the CPU complex, in the SOC.

69. A method as in any preceding embodiment wherein a thread can initiate outbound communication with its APIC/GIC using noncached reads and writes, which go over the data fabric.

70 A method as in any preceding embodiment wherein an APIC/GIC can initiate inbound communication with its thread using the interrupt channel.

71. A method as in any preceding embodiment wherein there is a bank of GIC or APIC blocks outside a CPU complex.

72. A method as in any preceding embodiment wherein each CPU complex has a set of these interrupt controllers attached to it, with enough capacity for the number of threads in that CPU complex. 73. A method as in any preceding embodiment wherein a bank of interrupt controllers has a data fabric connection (using AXI) for register reads and writes from the processor threads, and for incoming interrupts from 10 devices, and the bank also has a control fabric connection (using AXI_SP) for interrupts and interrupt handshakes to the processor thread.

74. A method as in any preceding embodiment wherein an AXI_SP is like a subset of AXI with only one write channel in each direction.

75. A method as in any preceding embodiment wherein all the writes are posted.

76. A method as in any preceding embodiment wherein traffic to and from AXI_SP is merged onto SMN either by a modified SMN router or by a dedicated gasket block.

77. A method as in any preceding embodiment wherein SMN is used to connect interrupt traffic to a CPU complex, and onward to each core's SCFCTP block.

78. A method as in any preceding embodiment wherein SCFCTP drives physical interrupt wires into a core.

79. A method as in any preceding embodiment wherein an interrupt starts at an IO device and makes its way to the IO hub.

80. A method as in any preceding embodiment wherein an interrupt goes across the Scalable Data Fabric as a message- signaled interrupt, to the AXI port of the APIC/GIC bank.

81. A method as in any preceding embodiment wherein a CM delivers a message to a targeted APIC or GIC using a real AXI interface.

82. A method as in any preceding embodiment wherein an interrupt message goes across the AXI_SP bus into the SMN network.

83. A method as in any preceding embodiment wherein an SMN network routes an interrupt message to a CPU complex.

84. A method as in any preceding embodiment wherein inside a CPU complex the normal SMN routing hardware directs an interrupt message to a SCFCTP block of a targeted core. 85. A method as in any preceding embodiment wherein a SCFCTP block delivers an interrupt message across the L3I/Core boundary into the core's interrupt logic, using dedicated physical interrupt wires.

86. A method as in any preceding embodiment wherein any hardware handshakes that are necessary for interrupt delivery are managed by a SCFCTP block sending SMN write transactions back out to a GIC/APIC bank.

87. A method as in any preceding embodiment, further comprising an atomicity primitive to protect a read/modify/write sequence.

88. A method as in any preceding embodiment wherein an atomicity primitive is handled entirely in the LI data cache.

89. A method as in any preceding embodiment wherein an atomicity primitive is referred to as a cacheable lock.

90. A method as in any preceding embodiment wherein a buslock involves noncacheable addresses or span a cacheline boundary.

91. A method as in any preceding embodiment wherein in SDF bus locks are controlled by a centralized bus lock arbiter, in or near one of the coherent slaves.

92. A method as in any preceding embodiment wherein threads request a bus lock and an arbiter will tell every other thread to stop issuing transactions.

93. A method as in any preceding embodiment wherein an arbiter grants a bus lock to a requesting thread.

94. A method as in any preceding embodiment wherein a locking thread performs its atomic operation.

95. A method as in any preceding embodiment wherein the lock is released.

96. A method as in any preceding embodiment wherein a bus lock arbiter tells other threads they may resume issuing transactions.

97. A method as in any preceding embodiment wherein during a lock, all traffic from all other cores in a coherent domain is stalled. 98. A method as in any preceding embodiment wherein other cores in a coherent domain can continue to execute out of their LI and L2 caches, but any L2 miss will stall until the bus is unlocked.

99. A method as in any preceding embodiment, further comprising acquiring and finishing an outstanding bus lock sequence before completing an incoming DVMSync.

100. A method as in any preceding embodiment wherein a D bit write is atomic and once started a DVMSync can't be ordered ahead of it.

101. A method as in any preceding embodiment wherein bus locks flow during a DVMSync sequence.

102. A method as in any preceding embodiment wherein a memory controller knows which cores are in CC6.

103. A method as in any preceding embodiment wherein there are corner cases around the transitions into and out of CC6.

104. A method as in any preceding embodiment wherein a core (e.g., x86 microcode, ARM software) performs a handshake, via register write, with the memory controller.

105. A method as in any preceding embodiment wherein during CC6 entry, the core tells the memory controller it is finished doing bus transactions and shutting down, so the memory controller does not expect any BusLockGrant requests from the core anymore.

106. A method as in any preceding embodiment wherein during CC6 exit and during reset, the core tells the memory controller it is about to start doing bus transactions again, so the memory controller should start expecting BusLockGrant requests from the core in response to BusLockReq messages

107. A method as in any preceding embodiment comprising receiving, by a lock master, a lock request from a first processor in a system.

108. A method as in any preceding embodiment, further comprising sending, by a lock master, a quiesce request to all processors in the system. 109. A method as in any preceding embodiment wherein, upon receipt of the quiesce request from a lock master, ceasing issuing, by all processors, a new transaction and issuing a quiesce granted transaction.

110. A method as in any preceding embodiment wherein, upon receipt of the quiesce granted transactions from all processors, issuing, by the lock master, a lock granted message, wherein the lock granted message issued by the lock master includes an identifier of the first processor.

111. A method as in any preceding embodiment, further comprising performing, by the first processor, an atomic transaction sequence and sending a first lock release message to the lock master upon completion of the atomic transaction sequence.

112. A method as in any preceding embodiment, further comprising sending, by the lock master, a second lock release message to all processors upon receiving the first lock release message from the first processor.

113. A method as in any preceding embodiment, further comprising the first processor comparing the identifier included in the lock granted message to the identifier of the first processor.

114. A method as in any preceding embodiment, further comprising the lock master queuing multiple lock requests received from processors other than the first processor.

115. A method as in any preceding embodiment, further comprising at least one processor sending a message to the lock master to join or leave an active set of processors.

116. A method as in any preceding embodiment wherein the at least one processor sends a message to join the active set of processors upon attaining an awake state.

117. A method as in any preceding embodiment wherein the at least one processor sends a message to leave the active set of processors upon entering a sleep state.

118. A method as in any preceding embodiment, further comprising the lock master counting the number of quiesce granted messages received from the processors, and sending the lock granted messages upon determining that quiesce granted messages are received from all active processors.

119. An apparatus configured to perform a method as in any preceding embodiment.

120. A system configured to perform a method as in any of embodiments

1-118.

" " "

Claims

CLAIMS What is claimed is:

1. A method comprising:

receiving, by a lock master, a lock request from a first processor in a system; sending, by the lock master, a quiesce request to all processors in the system; upon receipt of the quiesce request from the lock master, ceasing issuing, by all processors, a new transaction and issuing a quiesce granted transaction;

upon receipt of the quiesce granted transactions from all processors, issuing, by the lock master, a lock granted message, wherein the lock granted message issued by the lock master includes an identifier of the first processor;

performing, by the first processor, an atomic transaction sequence and sending a first lock release message to the lock master upon completion of the atomic transaction sequence; and

sending, by the lock master, a second lock release message to all processors upon receiving the first lock release message from the first processor.

2. The method of claim 1, further comprising the first processor comparing the identifier included in the lock granted message to the identifier of the first processor.

3. The method of claim 1 further comprising the lock master queuing multiple lock requests received from processors other than the first processor.

4. The method of claim 1, further comprising at least one processor sending a message to the lock master to join or leave an active set of processors.

5. The method of claim 4 wherein the at least one processor sends a message to join the active set of processors upon attaining an awake state.

6. The method of claim 4 wherein the at least one processor sends a message to leave the active set of processors upon entering a sleep state.

7. The method of claim 4, further comprising the lock master counting the number of quiesce granted messages received from the processors, and sending the lock granted messages upon determining that quiesce granted messages are received from all active processors.

8. A system, comprising:

a plurality of processors; and

a lock master; and

wherein the lock master is configured to receive a lock request from a first processor of the plurality of processors in the system, send a quiesce request to all processors in the system, upon receipt of a quiesce granted transaction from all processors, issue a lock granted message, wherein the lock granted message issued by the lock master includes an identifier of the first processor, and send a second lock release message to all processors upon receiving a first lock release message from the first processor.

9. The system of claim 8 wherein upon receipt of the quiesce request from the lock master, all processors cease a new transaction and issue the quiesce granted transaction.

10. The system of claim 8 wherein upon receipt of the lock granted message, the first processor is configured to perform an atomic transaction sequence and send the first lock release message to the lock master upon completion of the atomic transaction sequence.

11. The system of claim 8 wherein the first processor is configured to compare the identifier included in the lock granted message to the identifier of the first processor.

12. The system of claim 8 wherein the lock master is configured to queue multiple lock requests received from processors other than the first processor.

13. The system of claim 8 wherein at least one processor is configured to send a message to the lock master to join or leave an active set of processors.

14. The system of claim 13 wherein the at least one processor sends a message to join the active set of processors upon attaining an awake state.

15. The system of claim 13 wherein the at least one processor sends a message to leave the active set of processors upon entering a sleep state.

16. The system of claim 13 wherein the lock master is configured to count the number of quiesce granted messages received from the processors, and send the lock granted messages upon determining that quiesce granted messages are received from all active processors.

17. An apparatus comprising:

circuitry configured to receive a lock request from a first processor of a plurality of processors in a system, send a quiesce request to all processors in the system, upon receipt of a quiesce granted transactions from all processors, issue a lock granted message, wherein the lock granted message includes an identifier of the first processor, and send a second lock release message to all processors upon receiving a first lock release message from the first processor.

18. The apparatus of claim 17, further comprising circuitry configured to count the number of quiesce granted messages received from the processors, and send the lock granted messages upon determining that quiesce granted messages are received from all active processors.