Browse Prior Art Database

Shared Interrupt Target Groups in a Simulated-Processor System Disclosure Number: IPCOM000250014D
Publication Date: 2017-May-16
Document File: 3 page(s) / 241K

Publishing Venue

The Prior Art Database

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 48% of the total text.

Shared Interrupt Target Groups in a Simulated-Processor System

Disclosed is a method and a data structure for delivering processor interrupts to hierarchically

organized software targets in a single threaded simulator.

New data-center-targeted processors are moving to an environment where IDs for software

entities (such as hypervisor threads, OS virtual processors, and user level application

processes/threads) are being programmed into the interrupt hardware on each processor thread in

order to more efficiently deliver interrupts. For example, future UNIX systems may support

more than 6,000 concurrent software entity IDs.

Further, the IDs for each software entity (called an interrupt target) are organized hierarchically

into interrupt groups. For example, an interrupt may be serviced by any one of a group of 32 OS

virtual processors without any specific preference to which of the 32 OS virtual processors

services the interrupt. On some architectures, this is accomplished by setting the high-order bits

of the interrupt target IDs to the same value, and the low-order bits of the interrupt target IDs to

unique values. To use the same example, the bits 0b10000000000011nnnnn can specify a target

group with 32 members, and each individual target will be enumerated in the low-order 5 bits.

Thus, an interrupt can be targeted at the group 0b10000000000011nnnnn, and the processor

interrupt hardware will deliver it to 0b1000000000001100000, or0b1000000000001100001, or

0b1000000000001111111, etc., based on which entities are dispatched and programmed into the

thread logic at the time.

Simulations often run single threaded, trading accuracy for performance. However, scanning

6,000 or more interrupt target IDs across many CPU sockets, every time an interrupt comes in, is

an inefficiency (it is more efficient on hardware - even ignoring running on HW versus

Simulation speeds - because the scan is naturally done in parallel on HW). On a simulated

system, the simulation model keeps track of which interrupt target groups are in use by the

software running on the simulated system. When an interrupt target is dispatched or un-

dispatched, the list (or sparse tree) of tracked interrupt target groups is checked and a list of

dispatched members of the group is updated. When an interrupt needs to be delivered, the

list/tree of tracked interrupt target groups is referenced, and the hardware location to raise the

interrupt can be found by referencing the list for the target group.

Further, the list/tree of targeted interrupt groups can be persisted across runs of the simulator,

and even shared among multiple users running the same models and software, so that the

interrupt calculations done by a single model can be re-used again without having to re-do the

work. This will speed up the simulation both at start-up time (by using the shared interrupt

groups) and at run-time (by referencing the shared groups when delivering interrupts rather than

scanning each thread ser...