LOADING MANAGEMENT HYPERVISORS FROM USER SPACE

Disclosed are various examples of loading management hypervisors from user space. In some examples, a host device executes a first stage bootloader of a management hypervisor from within a host operating system. The first stage bootloader loads management hypervisor data and handoff instructions into a memory of the host device, and invokes a kernel execute call of the host operating system. The handoff instructions invoke a second stage bootloader that configures and launches the management hypervisor using the management hypervisor data.

BACKGROUND

Enterprises can employ a management service that uses virtualization to provide the enterprise with access to software, data, and other resources. The management service use host devices to execute workloads that provide software services for enterprise activities. The enterprises can use other host devices to access these workloads

Booting management hypervisors in traditional systems can impose a number of requirements on the system firmware. For example, Unified Extensible Firmware Interface (UEFI) firmware can use drivers for video, console, storage, network for a preboot execution environment (PXE) or other uses, and so on. These drivers can require significant investment on the side of the platform integrator, enterprises, and management services, and device providers. As a result, UEFI-based solutions can be difficult or costly to implement. Some devices can lack UEFI, or can lack a UEFI that includes drivers for all device hardware used by the management hypervisor. However, the present disclosure describes mechanisms that can execute a first stage bootloader of a management hypervisor as a Linux or POSIX-like user-space application, rather than a kernel space or other privileged mode driver or application. The first stage bootloader can use block, filesystem, network, console, and I/O facilities and system calls to a preinstalled operating system to build the boot data handoff structures including memory maps and hardware identification and descriptions for hardware resources of a host device.

DETAILED DESCRIPTION

The present disclosure describes implementations of loading a management hypervisor from user space of a preinstalled operating system. Booting management hypervisor in traditional systems can impose a number of requirements on the system firmware. Unified Extensible Firmware Interface (UEFI) firmware can use drivers for video, console, storage, a network for a preboot execution environment (PXE) or other uses, and so on. The driver requirements can cause significant investment on the side of the platform integrator, enterprises, and management services, and device providers. As a result, UEFI-based solutions can be difficult or costly to implement. Some devices can lack firmware capable of installing the management hypervisor. For example, the devices can lack UEFI, or can lack a UEFI that includes drivers for host device hardware. However, the present disclosure describes mechanisms that can execute a first stage bootloader of a management hypervisor as a Linux or POSIX-like user-space application, rather than a privileged driver or privileged application that operates in an exception level, ring, or other privilege higher than user space. The first stage bootloader can use block, filesystem, network, console, and I/O facilities and system calls to the preinstalled operating system to build the boot data handoff structures including memory maps and hardware identification and descriptions for host hardware resources.

With reference toFIG.1, shown is an example of a networked environment100. The networked environment100can include a management system103, host devices106, and other components in communication with one another over a network112. In some cases, host devices106can include computing devices or server computing devices of a private cloud, public cloud, hybrid cloud, and multi-cloud infrastructures. Hybrid cloud infrastructures can include public and private host computing devices. Multi-cloud infrastructures can include multiple different computing platforms from one or more service providers in order to perform a vast array of enterprise tasks.

The host devices106can also include devices that can connect to the network112directly or through an edge device or gateway. The components of the networked environment100can be utilized to provide virtualization solutions for an enterprise. The hardware of the host devices106can include physical memory, physical processors, physical data storage, and physical network resources that can be utilized by virtual machines. Host devices106can also include peripheral components such as the host devices106. The host devices106can include physical memory, physical processors, physical data storage, and physical network resources. Virtual memory, virtual processors, virtual data storage, and virtual network resources of a virtual machine can be mapped to physical memory, physical processors, physical data storage, and physical network resources of the host devices106. The management hypervisor155can provide access to the physical memory, physical processors, physical data storage, and physical network resources of the host devices106to perform workloads130.

A host device106can, in some examples, include a DPU device, a single board computer (SBC) device, a system-on-chip (SoC) device, and other types of devices. These simple, limited, or integrated device types can lack the firmware requirements to install a management hypervisor155. These devices can lack Unified Extensible Firmware Interface (UEFI), or can lack a UEFI that includes drivers for host device hardware. A DPU device can include networking accelerator devices, smart network interface cards, or other cards that are installed as a peripheral component to another host device106.

The management hypervisor155can be integrated with the management service120, which provides device management functionalities. The management hypervisor155can communicate with the management service120to provide access to the physical memory, physical processors, physical data storage, physical network resources, and physical accelerator resources of the host device106for workloads130. The management hypervisor155can also communicate with the management service120to provide the host device106with access to workloads130. However, the management hypervisor155may not be initially installed to the host device106.

Virtual devices including virtual machines, containers, and other virtualization components can be used to execute the workloads130. The workloads130can be managed by the management service120for an enterprise that employs the management service120. Some workloads130can be initiated and accessed by enterprise users through client devices. The virtualization data129can include a record of the virtual devices, as well as the host devices106and host devices106that are mapped to the virtual devices. The virtualization data129can also include a record of the workloads130that are executed by the virtual devices.

The network112can include the Internet, intranets, extranets, wide area networks (WANs), local area networks (LANs), wired networks, wireless networks, other suitable networks, or any combination of two or more such networks. The networks can include satellite networks, cable networks, Ethernet networks, telephony networks, and other types of networks.

The management system103can include one or more host or server computers, and any other system providing computing capability. In some examples, a subset of the host devices106can provide the hardware for the management system103. While referred to in the singular, the management system103can include a plurality of computing devices that are arranged in one or more server banks, computer banks, or other arrangements. The management system103can include a grid computing resource or any other distributed computing arrangement. The management system103can be multi-tenant, providing virtualization and management of workloads130for multiple different enterprises. Alternatively, the management system103can be customer or enterprise-specific.

The computing devices of the management system103can be located in a single installation or can be distributed among many different geographical locations which can be local and/or remote from the other components. The management system103can also include or be operated as one or more virtualized computer instances. For purposes of convenience, the management system103is referred to herein in the singular. Even though the management system103is referred to in the singular, it is understood that a plurality of management systems103can be employed in the various arrangements as described above.

The components executed on the management system103can include a management service120, as well as other applications, services, processes, systems, engines, or functionality not discussed in detail herein. The management service120can be stored in the data store123of the management system103. While referred to generally as the management service120herein, the various functionalities and operations discussed can be provided using a management service120that includes a scheduling service and a number of software components that operate in concert to provide compute, memory, network, and data storage for enterprise workloads and data. The management service120can also provide access to the enterprise workloads and data executed by the host devices106and can be accessed using client devices that can be enrolled in association with a user account126and related credentials.

The management service120can communicate with associated management instructions executed by host devices106, client devices, edge devices, and IoT devices to ensure that these devices comply with their respective compliance rules124, whether the specific host device106is used for computational or access purposes. If the host devices106or client devices fail to comply with the compliance rules124, the respective management instructions can perform remedial actions including discontinuing access to and processing of workloads130.

The data store123can include any storage device or medium that can contain, store, or maintain the instructions, logic, or applications described herein for use by or in connection with the instruction execution system. The data store123can be a hard drive or disk of a host, server computer, or any other system providing storage capability. While referred to in the singular, the data store123can include a plurality of storage devices that are arranged in one or more hosts, server banks, computer banks, or other arrangements. The data store123can include any one of many physical media, such as magnetic, optical, or semiconductor media. More specific examples include solid-state drives or flash drives. The data store123can include a data store123of the management system103, mass storage resources of the management system103, or any other storage resources on which data can be stored by the management system103. The data store123can also include memories such as RAM used by the management system103. The RAM can include static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), and other types of RAM.

The data stored in the data store123can include management data including device data122, enterprise data, compliance rules124, user accounts126, and device accounts128, as well as other data. Device data122can identify host devices106by one or more device identifiers, a unique device identifier (UDID), a media access control (MAC) address, an internet protocol (IP) address, or another identifier that uniquely identifies a device with respect to other devices.

The device data122can include an enrollment status indicating whether a host computing device is enrolled with or managed by the management service120. For example, an end-user device, an edge device, IoT devices, client devices, and other host devices106can be designated as “enrolled” and can be permitted to access the enterprise workloads and data hosted by host devices106, while those designated as “not enrolled,” or having no designation, can be denied access to the enterprise resources. The device data122can further include indications of the state of IoT devices, edge devices, end user devices, host devices106, and other devices. While a user account126can be associated with a particular person as well as client devices, a device account128can be unassociated with any particular person, and can nevertheless be utilized for an IoT device, edge device, or another client device or host device106that provides automatic functionalities.

Device data122can also include data pertaining to user groups. An administrator can specify one or more of the host devices106as belonging to a user group. The user group can refer to a group of user accounts126, which can include device accounts128. User groups can be created by an administrator of the management service120.

Compliance rules124can include, for example, configurable criteria that must be satisfied for the host devices106and other devices to be in compliance with the management service120. The compliance rules124can be based on a number of factors, including geographical location, activation status, enrollment status, and authentication data, including authentication data obtained by a device registration system, time, and date, and network properties, among other factors associated with each device. The compliance rules124can also be determined based on a user account126associated with a user.

Compliance rules124can include predefined constraints that must be met in order for the management service120, or other applications, to permit host devices106and other devices access to enterprise data and other functions of the management service120. The management service120can communicate with management instructions on the client device to determine whether states exist on the client device which do not satisfy one or more of the compliance rules124. States can include, for example, a virus or malware being detected; installation or execution of a blacklisted application; and/or a device being “rooted” or “jailbroken,” where root access is provided to a user of the device. Additional states can include the presence of particular files, questionable device configurations, vulnerable versions of applications, vulnerable states of the client devices or another vulnerability, as can be appreciated. While the client devices can be discussed as user devices that access or initiate workloads130that are executed by the host devices106, all types of devices discussed herein can also execute virtualization components and provide hardware used to host workloads130.

The management service120can oversee the management and resource scheduling using hardware provided by using host devices106. The management service120can oversee the management and resource scheduling of services that are provided to the host devices106using remotely located hardware. The management service120can transmit various software components, including enterprise workloads, enterprise data, and other enterprise resources for processing and storage using the various host devices106. The host devices106can include a server computer or any other system providing computing capability, including those that compose the management system103. Host devices106can include public, private, hybrid cloud and multi-cloud devices that are operated by third parties with respect to the management service120. The host devices106can be located in a single installation or can be distributed among many different geographical locations which can be local and/or remote from the other components.

The management service120can include a scheduling service that monitors resource usage of the host devices106, and particularly the host devices106that execute enterprise workloads130. The management service120can also track resource usage of DPU devices that are installed on the host devices106. The management service120can track the resource usage of DPU devices in association with the host devices106to which they are installed. The host device106can execute instructions including a host operating system150, a management component151(e.g., in user space) and a management hypervisor155.

The host operating system150can include an operating system that provides a user interface and an environment for applications and other instructions executed by the host device106. The host operating system150can include any operating system. In some examples, the host operating system150can include a Linux operating system, a POSIX operating system, a Windows operating system such as Windows Server®, or another operating system.

The management component151can communicate with the management service120for scheduling of workloads130executed using virtual resources that are mapped to the physical resources of one or more host device106. The management component151can communicate with the management hypervisor155to deploy virtual devices that perform the workloads130. In various embodiments, the management component151can be separate from, or a component of, the management hypervisor155.

The management hypervisor155can include a bare metal or type1hypervisor that can provide access to the physical memory, physical processors, physical data storage, and physical network resources of the host devices106to perform workloads130. A management hypervisor155can create, configure, reconfigure, and remove virtual machines and other virtual devices on a host device106. The management hypervisor155can also relay instructions from the management service120to the management hypervisor155. In other cases, the management service120can communicate with the management hypervisor155directly. The management hypervisor155can identify that a workload130or a portion of a workload130includes instructions that can be executed using the host device106.

The management hypervisor155can operate independently from the host operating system. As a result, the host operating system150can include a preinstalled operating system that is preinstalled and packaged by the manufacturer or vendor of the host device106, or another operating system. In some examples, a preinstalled host operating system150can be replaced with another host operating system150prior to execution of the management hypervisor first stage bootloader163. Alternatively, a preinstalled host operating system150can be replaced with another host operating system150by the management hypervisor155or during the installation process of the management hypervisor155.

The management hypervisor first stage bootloader163can be considered a portion of the management hypervisor155that runs as a user space application in the host operating system150. The management hypervisor first stage bootloader163can be configured to execute during a boot process or as a startup process of the host operating system150. The management hypervisor first stage bootloader163can load a kernel of the management hypervisor155into host memory, build and load boot data handoff structures that enable the management hypervisor155to use hardware resources of the host device106, load ‘trampoline’ or ‘handoff’ instructions into host main memory, and invoke a kernel execute system call of the host operating system150. The kernel execute system call can cause the host device106to reboot and execute the handoff instructions or handoff region in host memory. The kernel execute call can be invoked at a physical address or address region corresponding to the handoff instructions. The handoff instructions can move the management hypervisor155kernel and/or other data loaded into memory by the management hypervisor first stage bootloader163into memory areas that are unavailable to user space applications such as the first stage bootloader.

FIG.2shows an example of the host device106that loads a management hypervisor155from user space of a host operating system150. The host device106can include host hardware resources203, host firmware206, the host operating system150, and the management hypervisor155.

The host hardware resources203can include a main processor such as an ARM processor or another RISC- or CISC-based processor. The host hardware resources203can include one or more memory including flash, Non-Volatile Memory Express (NVMe) devices, and other memory devices. The host hardware resources203can include specialized ASICs including a network interface card (NIC) ASICs, network processing units (NPU) ASICs, field programmable gate array (FPGA) based ASICs, software switches, Programming Protocol-independent Packet Processors (P4) devices, NVIDIA® ConnectX®-6 Dx (CX6) devices, and others.

The host firmware206can include Trusted Firmware A (TF-A), Unified Extensible Firmware Interface (UEFI) or another publicly available specification that defines a software interface, Advanced Configuration and Power Interface, a power management specification (ACPI) or another power management firmware, and other firmware for the host device106. However, as indicated earlier, the host firmware206can lack UEFI or can include a UEFI that has insufficient drivers for the host hardware resources203. This can cause the UEFI to be unable to initialize, load, and execute the management hypervisor155.

The management hypervisor first stage bootloader163can be configured to execute during a boot process or as a startup process of the host operating system150. The management hypervisor first stage bootloader163can load management hypervisor data209into host memory.

The management hypervisor data209can include a management hypervisor kernel212and boot data handoff structures215. The boot data handoff structures215can include memory maps for host memory, memory locations for the management hypervisor kernel212, as well as descriptions and identifications of host hardware resources203. In order to build the boot data handoff structures215, the management hypervisor first stage bootloader163can use block, filesystem, network, and console I/O as necessary. Alternatively, the boot data handoff structures215can be predetermined for the host device106and included in, or side loaded for access by, the management hypervisor first stage bootloader163.

The management hypervisor first stage bootloader163can run in its own virtual address space. When the management hypervisor first stage bootloader163needs to identify memory into which to load a boot module for the management hypervisor155or another boot data handoff structure215, it can use system calls to the host operating system150. The system calls can include malloc, memalign, mmap, mlock, and other calls. However, the memory and other hardware addresses returned have no meaning outside of the management hypervisor first stage bootloader163process. For example, the addresses can be virtual addresses. The management hypervisor first stage bootloader163can translate these to physical or machine addresses, and use physical addresses to build the boot data handoff structures215. In the example where the host operating system150is a Linux operating system, the method for translating can include using a /proc/self/pagemap mechanism or another pagemap mechanism to translate addresses, where self refers to a process identifier for the management hypervisor first stage bootloader163. This interface can include a file in the host operating system150file system in the location that can be specified using /proc/self/pagemap. The memory allocate call or malloc call can be pinned to avoid from getting paged out. Pinned memory can refer to virtual memory pages that are specially marked so that they cannot be paged out based on system API function calls that can pin or prevent paging out of the memory. This can include mlock calls for allocated memory. The management hypervisor first stage bootloader163can identify or capture memory data for the boot data handoff structures215and management hypervisor kernel212by parsing /proc/firmware/memmap, /sys/firmware/memmap, or another interface or file that provides a raw memory map to userspace.

In some examples such as when the management hypervisor155is booting using UEFI, ACPI/DeviceTree and System Management BIOS (SMBIOS) data can be identified from UEFI of the host firmware206by parsing system table and configuration table interfaces or files available to userspace. The system table interface or file can be accessed using /sys/firmware/efi/systab. The configuration table interface or file available from userspace can be accessed through /sys/firmware/efi/config table. Runtime UEFI regions can be ignored. In some examples request Tracker (RT) services are not or cannot be reused due to different virtual address ranges used for RT by the SPU provider OS161and the management hypervisor155and the management hypervisor first stage bootloader163.

However, the management hypervisor first stage bootloader163can include non-UEFI data identification and definition mechanisms as well. If UEFI is not used, a device tree can be used verbatim from a user space device tree interface or file such as /proc/devicetree or an ACPI/DeviceTree loaded from file. The device tree can be a data structure and language for identifying and describing hardware. This can be a portion of the boot data handoff structures215that includes a description of host hardware that is readable by the management hypervisor155so that the management hypervisor kernel212doesn't need to hard code machine details of the host device106. Video framebuffer device information can be initialized using a user space interface or file such as /dev/fb0. The video framebuffer data can also be part of the boot data handoff structures215.

The management hypervisor first stage bootloader163can provide boot data handoff structures215to enable the management hypervisor155and the second stage bootloader211to use hardware resources of the host device106, load handoff or handoff instructions218into host memory, and invoke a kernel execute system call of the host operating system150. The kernel execute system call can cause the host device106to reboot and execute the handoff instructions218. The handoff instructions218can move the management hypervisor155kernel and other data loaded into memory by the management hypervisor first stage bootloader163into memory areas that are unavailable to user space applications such as the first stage bootloader. The handoff instructions218can be referred to as management hypervisor handoff instructions or management hypervisor handoff instructions that prepare the host device106for execution of the management hypervisor155once the kernel execute call is invoked.

The management hypervisor first stage bootloader163can identify information for management hypervisor data209including how much physical memory there is, which portions of the physical memory are unusable to boot the management hypervisor155, and where to initially and ultimately place the management hypervisor second stage bootloader211, the management hypervisor kernel212, the boot data handoff structures215, and other data. Since there is a host operating system150currently in memory, but it will no longer be in memory once the management hypervisor155is executed, one or more of the management hypervisor kernels212and the boot data handoff structures215can be initially loaded into one location in host memory, and then moved into a memory location previously occupied by the host operating system150by the handoff instructions218. The handoff instructions218can also move these items into other memory locations that are unavailable to the management hypervisor first stage bootloader163based on the existence of other data that will be cleared or areas that are not available from user space.

The management hypervisor second stage bootloader211can be a kernel space bootloader. The management hypervisor second stage bootloader211can validate the management hypervisor kernel212, and other boot modules and proceed with launching the management hypervisor155using the boot data handoff structures215stored in host memory. The host memory can refer to static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), and other types of RAM and other memories. The handoff instructions218can launch the management hypervisor second stage bootloader211with a predetermined set of options as well as provided memory locations of the boot data handoff structures215.

The management hypervisor155can operate in EL2 privilege level. Exception levels (e.g., EL0, EL1, EL2, EL3) can correspond to Advanced RISC Machine (ARM) privilege levels. EL0 can refer to application mode or user space privilege, EL1 can refer to kernel space or rich OS privilege, EL2 can refer to hypervisor privilege, and EL3 can refer to firmware or secure monitor privilege level. The discussion can include reference to exception levels since some host devices106can include ARM processors as a main processor. RISC-V privilege levels can include user-mode (U-mode), supervisor mode (S-mode), and machine mode (M-mode). In a RISC-V host device106implementation, U-mode can correspond to a user space privilege, S-mode can correspond to kernel, operating system, and/or hypervisor privilege, and machine mode can correspond to firmware or secure monitor privilege. However, other host devices106can include other processor types and privilege levels corresponding to other labels and designations such as ring levels of x86 devices.

FIG.3shows a flowchart300that provides an example of the operation of components of the networked environment100. Generally, this figure provides an example of functionality of a management hypervisor first stage bootloader163that loads a management hypervisor155from user space of a host operating system150. While a particular step can be discussed as being performed by a particular hardware or software component of the networked environment100, other components can perform aspects of that step.

In step303, the host device106can execute a management hypervisor first stage bootloader163. The management hypervisor first stage bootloader163can be considered a portion of the management hypervisor155that runs as a user space application in the host operating system150. The management hypervisor first stage bootloader163can be configured to execute during a boot process or as a startup process of the host operating system150.

In step306, the management hypervisor first stage bootloader163can load a management hypervisor second stage bootloader211and a management hypervisor kernel212into main CPU memory208. The main CPU memory208areas or address range for the management hypervisor second stage bootloader211and the management hypervisor kernel212can be pinned using a system call. The management hypervisor first stage bootloader163can identify memory into which to load the management hypervisor kernel212by system calls to the host operating system150to identify virtual memory addresses. The management hypervisor first stage bootloader163can translate the addresses returned by the system call into physical or machine addresses for the management hypervisor kernel212. Translation can be performed using a pagemap mechanism.

In step309, the management hypervisor first stage bootloader163can build and load boot data handoff structures215. The management hypervisor first stage bootloader163can use block, filesystem, network, console, and I/O facilities and system calls to the host operating system150to build the boot data handoff structures215. The structures can include modules of the management hypervisor155, memory maps of the host device106, and hardware identification and descriptions for host hardware resources203of the host device106.

The management hypervisor first stage bootloader163can identify memory into which to load the boot data handoff structures215by system calls to the host operating system150to identify virtual memory addresses, and translating these addresses into physical machine addresses. The host memory areas or address ranges for the boot data handoff structures215can be pinned using a system call.

In step312, the management hypervisor first stage bootloader163can load handoff instructions218into memory of the host device106. The management hypervisor first stage bootloader163can identify memory into which to load the handoff instructions218by system calls to the host operating system150to identify virtual memory addresses, and translate these addresses into physical machine addresses. The host memory areas or address ranges for the handoff instructions218can be pinned using a system call.

In step315, the management hypervisor first stage bootloader163can invoke a kernel execute system call to the handoff instructions218. The kernel execute system call can be called to the handoff instructions218, and the handoff instructions218can further prepare the host device106for execution of the management hypervisor155using kernel space facilities that are unavailable to the management hypervisor first stage bootloader163as a user space application. The handoff instructions218can also call a management hypervisor second stage bootloader211, which can further prepare the host device106and launch or execute the management hypervisor155.

FIG.4shows a flowchart400that provides an example of the operation of components of the networked environment100. Generally, this figure provides an example of functionality of a handoff instructions218invoked to execute from user space. The handoff instructions218can perform actions that load and execute a management hypervisor155. While a particular step can be discussed as being performed by a particular hardware or software component of the networked environment100, other components can perform aspects of that step.

In step403, the handoff instructions218can be executed. The handoff instructions218can be executed based on a kernel execute system call to the handoff instructions218. A user space application such as the management hypervisor first stage bootloader163can perform the kernel execute system call that specifies a physical address or address region of the handoff instructions218.

In step406, the handoff instructions218can move or shift management hypervisor data209. In various examples, the management hypervisor kernel212, the second stage bootloader, the boot data handoff structures215can be in a suboptimal location. The handoff instructions218can be configured to move all or a portion of the management hypervisor data209. One benefit of the trampoline or handoff instructions218is that some kernel execute calls can be limited to a predetermined number of segments such as 16 or another number, which can make a direct call to the second stage bootloader or another portion of the management hypervisor155problematic.

In step409, the handoff instructions218can invoke a second stage bootloader of the management hypervisor155. The handoff instructions218can invoke the second stage bootloader along with a pointer to the physical address of the boot data handoff structures215. The second stage bootloader can further prepare the host device106using the boot data handoff structures215and then execute the management hypervisor155using the management hypervisor kernel212.

In step412, the host device106can perform a workload130using the host hardware resources203or provide the host device106with access to a workload130executed using a remotely located host device106. The host device106can receive a command to perform a workload130through the management hypervisor155. The host device106can perform the workload130using host hardware resources203that are accessed using the management hypervisor155. The host device106can transmit a request for access to a workload130, or can receive a command to provide the host device106with access to a workload130. The management hypervisor155can provide access to the workload130or other management service or enterprise resources such as data stores, applications, and other resources.

A number of software components are stored in the memory and executable by a processor. In this respect, the term “executable” means a program file that is in a form that can ultimately be run by the processor. Examples of executable programs can be, for example, a compiled program that can be translated into machine code in a format that can be loaded into a random access portion of one or more of the memory devices and run by the processor, code that can be expressed in a format such as object code that is capable of being loaded into a random access portion of the one or more memory devices and executed by the processor, or code that can be interpreted by another executable program to generate instructions in a random access portion of the memory devices to be executed by the processor. An executable program can be stored in any portion or component of the memory devices including, for example, random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, USB flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape, or other memory components.

Memory devices can include both volatile and nonvolatile memory and data storage components. Also, a processor can represent multiple processors and/or multiple processor cores, and the one or more memory devices can represent multiple memories that operate in parallel processing circuits, respectively. Memory devices can also represent a combination of various types of storage devices, such as RAM, mass storage devices, flash memory, or hard disk storage. In such a case, a local interface can be an appropriate network that facilitates communication between any two of the multiple processors or between any processor and any of the memory devices. The local interface can include additional systems designed to coordinate this communication, including, for example, performing load balancing. The processor can be of electrical or of some other available construction.

The sequence diagrams and flowcharts can show examples of the functionality and operation of an implementation of portions of components described herein. If embodied in software, each block can represent a module, segment, or portion of code that can include program instructions to implement the specified logical function(s). The program instructions can be embodied in the form of source code that can include human-readable statements written in a programming language or machine code that can include numerical instructions recognizable by a suitable execution system such as a processor in a computer system or another system. The machine code can be converted from the source code. If embodied in hardware, each block can represent a circuit or a number of interconnected circuits to implement the specified logical function(s).

Although sequence diagrams and flowcharts can be shown in a specific order of execution, it is understood that the order of execution can differ from that which is depicted. For example, the order of execution of two or more blocks can be scrambled relative to the order shown. Also, two or more blocks shown in succession can be executed concurrently or with partial concurrence. Further, in some embodiments, one or more of the blocks shown in the drawings can be skipped or omitted.

The computer-readable medium can include any one of many physical media, such as magnetic, optical, or semiconductor media. More specific examples of a suitable computer-readable medium include solid-state drives or flash memory. Further, any logic or application described herein can be implemented and structured in a variety of ways. For example, one or more applications can be implemented as modules or components of a single application. Further, one or more applications described herein can be executed in shared or separate computing devices or a combination thereof. For example, a plurality of the applications described herein can execute in the same computing device, or in multiple computing devices.