In large systems, there may be more than one subcomponent that is running software. For instance, there may be one main multicore processor that runs software in main memory, and in addition to that there is a plugin card that runs specialized software on specialized hardware, for instance for traffic processing on a line card. Another example is a frontend processor controlling the main system.
Each of these subsystems that run software separately from the others is said to form a software domain, which means that all the processor cores in the domain are of the same architecture, and that they share physical memory. Different software domains in the same large-scale system can be of different architectures and have separate physical memory for each domain.
Being a software domain is purely a property of the hardware, and does not say anything about what software is running on the system. In some cases, the software layer will create its own layer of virtual software domains, for instance by partitioning a multicore processor and running different operating systems on different cores, using separate parts of the shared memory. It is also possible to create distributed shared memory systems that unify several systems at the software level. These software configurations do not change how software domains are defined at the Simics level, the software domains are independent of what software is running in the system.
Software domains are determined by the hardware configuration, before it is known what software is going to be loaded onto the system.
In Simics configurations, a software domain is represented by an os_awareness object that references a group of processors that form the domain. The physical memory used by the software is implicitly defined by the processors which are assumed to share memory, or at least the parts of memory where software resides.
In the object hierarchy, the software domain object (class os_awareness) is typically called software and is is placed below the top object that contains the processors. The name 'software' is just a convention while the location in the object hierarchy may affect the set of processors that are part of the software domain. This is described in the next section (26.2).
The software domain object contains all the mechanisms and information needed to track the software running in the software domain, including a tracker object that can be configured with different software tracker modules.
The hardware model does not itself define any software domains, and does not rely on any software domains configured to use its processors.
The software domain object needs to know which processors it tracks software for. This can often be determined more or less automatically with support from the hardware models, but it is also possible to make the configuration more explicit, either by using the processors in the new-os-awareness command, or by setting the processors attribute on the software domain object.
The software domain object will use the following sources of processor information, in this order:
cpu_list, this is assumed to be a list of processors. If this list is not empty, it is used as the list of processors in the software domain.cpu_list attribute, or if the attribute is empty, then the object hierarchy below the parent object is searched for processor objects, and all found processors are used in the software domain. This search only uses the object hierarchy and does not follow connectors.If no processors are found using the above rules, it is a misconfiguration of the software domain.
Most configuration can use the cpu_list attribute to configure the software domains.
A software domain can have a software tracker associated with it. The tracker tracks what software is running on the system, limited to the software domain it is associated with. To perform this tracking, it is configured with one or more software tracker modules that implement the required logic to understand what the software is doing. Usually, there is a single tracker module that corresponds to the running operating system. For multi-layered software, such as a hypervisor running several guest operating systems, there can be one tracker module for the hypervisor and one tracker module for each guest.
The software domain object provides interfaces to access data collected by the tracker and listen to events from the tracker. This can be used by scripts and tools. See the Analyzer User's Guide for more details.
The software tracker talks to all the processors it handles, which means that they all need to belong to the same cell. In many cases, there will be a 1:1 mapping between cells and software domains, since the way Simics defines how the configuration can be divided into cells shares many properties with how software domains are defined.
However, in some cases there will be more than one software domain that is tightly connected in other ways than by sharing program memory, which means that they need to be in the same cell.