Virtual machines are emulated on a physical machine with each virtual machine having a subset of resources available on the physical machine. The NVIDIA Virtualization System is highly configurable, allowing every system to address different use cases and requirements for unique configuration.

This document describes the fundamentals of NVIDIA Virtualization System configuration and provides procedures for configuring virtual machines.

This document includes the following sections:

This section discusses the Partition Configuration Table (PCT), peripherals, and how they are used together

The Partition Configuration Table (PCT) is a proprietary mechanism for configuration of virtual machines according to NVIDIA Virtualization System requirements.

The PCT consists of the following components and characteristics:

The NVIDIA Tegra SoC consists of many sub-blocks. A set of sub-blocks comes together to provide desired high level functionality. In-depth knowledge of each of the sub-blocks and relationships between them is required to be able to assign a high level functionality to the virtual machine. To hide some of this complexity, the NVIDIA Virtualization System defines the concept of a peripheral.

A peripheral is a separately assignable computer system component. A peripheral may, for example, comprise such things as a collection of MMIO ranges, interrupt signals, power controls, clock controls, and/or reset controls.

Physical peripherals are peripherals in a physical machine. The NVIDIA Virtualization System refers to all peripherals assigned to a virtual machine as virtual peripherals.

Peripherals are related to device tree nodes that encapsulate all resources that a device driver requires to operate. A peripheral provides one more level of abstraction, encapsulating multiple device tree nodes.

There are two categories of peripheral:

Passthrough peripherals must be accessible by only one virtual machine. Once assigned to a virtual machine, virtual passthrough peripherals expose the exact same interface to the Guest OS as is exposed by a physical peripheral.

The PCT identifies each passthrough peripheral with a unique peripheral ID.

Shared peripherals support mapping of more than one virtual peripheral to one physical peripheral. Each virtual peripheral is an instance of the physical peripheral, usually with a subset of the capabilities supported by the physical peripheral. Each virtual peripheral is independent and meets NVIDIA Virtualization System isolation requirements.

NVIDIA Virtualization System uses the following mechanisms for implementing virtual peripherals:

Unlike passthrough peripherals, the hardware interface exposed by this class of peripheral to the Guest OS can be different from interfaces exposed by physical peripherals.

The NVIDIA Virtualization System does not distinguish between virtual peripherals based on the implementation mechanisms listed above. Other sections of this documentation describe the implementation mechanism for a virtual device to explain the configuration parameters.

Assignment of a virtual peripheral to a virtual machine maps the virtual peripheral resources, such as MMIO, IRQ, Clocks, and IVC interface, to the virtual machine.

The PCT provides a very simple configuration interface for assignment of passthrough peripherals to the virtual machine. This section describes the exact syntax for assignment of passthrough peripherals.

The PCT Peripheral Ownership data structure holds the assignment configuration, shown below:

Peripheral assignment is shown in the following example (from guest_io_periph_assign.h.):

Assignment of shared peripherals is a two-step process:

The PCT describes the capabilities associated with virtual peripherals and allows you to assign capabilities and instantiate a virtual peripheral. Because each peripheral is different, the capabilities described in the PCT for each shared peripheral are different. An understanding of the basic functionality provided by shared peripherals is needed to be able to assign capabilities and instantiate a virtual peripheral.

See Shared Peripheral Configuration in this chapter for details on PCT description for each shared peripheral.

Virtual peripherals implemented using the para-virtualization mechanism use the PCT-defined concept of a virtual peripheral interface, referred to as VInterface.

Normally the software interfaces with the peripheral using a register interface, but in cases where a virtual peripheral is implemented using a para-virtualization mechanism, the physical hardware is managed by the server partition. The server partition exposes an IVC channel-based interface for the driver running in the guest. The definition of the resulting pool of IVC channels is the VInterface.

The primary purpose of the PCT is assigning virtual peripherals to the virtual machine. The PCT allocates a unique identifier for each virtual machine. This allows NVIDIA Virtualization System to derive virtual peripheral ownership from the PCT blob. and based on that, assign the virtual peripherals to the virtual machine.

Instead of explicitly assigning an ID, the PCT auto-generates an ID based on the index with which the virtual machine is listed in the gconf data structure.

NVIDIA Virtualization System defines the concept of privileges, allowing the virtual machine to perform operations outside regular container boundaries. The PCT provides mechanisms to assign these privileges to virtual machines.

The following sections describe specific PCT characteristics.

PCT configuration belongs to a specific platform, consisting of the SoC and the board. It is possible to have multiple PCT configurations for a platform. Each such configuration is an independent product based on that particular platform.

Typically, all PCTs supported for a particular platform are kept in the same location. The naming convention followed for that location is <board>-<soc>, for example, p2382-t186. The naming of each PCT configuration folder contained in the platform folder is not rigid. Typically the name represents the Guest OS that is part of that PCT configuration.

(pct/p2382-t186/linux-linux) This is a PCT for the NVIDIA DRIVE™ CX 2 platform, based on the NVIDIA® Tegra® Code-Name Parker processor, that implements a dual-Linux system.

PCT configuration data is populated in the following header files.

This configuration file contains configuration required for creation of virtual machine and also assigns virtual devices to the virtual machine. Each entry in the guest_conf array instantiate a virtual machine. Each member of guest_conf structure specifies attributes, privileges or resources assigned to the virtual machine.

This configuration file contains configuration for 1. CPU/vCPU Assignment to virtual machine. 2. IVC Channels between virtual machines. 3. mempools or shared buffers between virtual machines.

This file contains configuration required for pct peripheral to virtual machine assignment.

This configuration file contains GPIO pin assignment to Virtual GPIO Controller.

This configuration file contains configuration for i2c slave assignment to Virtual I2C Controller.

This configuration file describes the storage layout for virtual machines. It constructs storage containers.

This configuration file describes the storage layout within virtual machines storage container.

This file associates macros to map Guest ID to more readable macros.

After changes are made in the PCT, it is necessary to compile the PCT and generate the PCT blob. The PCT blob is part of the NVIDIA DRIVE™ Foundation image, and the Foundation image must be regenerated with the newly created PCT blob. The bind_partitions tool is used to generates the PCT blob and the Foundation image.

NVIDIA Virtualization System implements APIs that allow VS elements to extract configuration information by parsing the PCT blob. This library is implemented for both the ARM and the X86 architectures, allowing both host and target software to parse the PCT blob.

This includes the procedure to configure shared peripherals for instantiation of virtual peripheral mapping to the shared peripherals. You can instantiate virtual peripherals with a subset of capabilities supported by physical peripherals and assign the virtual peripheral to a virtual machine.

Memory (system DRAM) is used to store code and data for computer programs, and generally it is directly accessible by the CPU and sometimes also by peripheral devices.

Virtual RAM is RAM that is private to the virtual machine and is not shared with other virtual machines.

The virtualization system uses several mechanisms including the Memory Management Unit (MMU) and the System Memory Management Unit (SMMU) to partition memory between virtual machines. The MMU and the SMMU form the foundation of the trusted computing base for the system.

Virtualization system configuration provides PCT parameters to allocate virtual RAM. This section describes these parameters. The amount of physical memory available to each VM (virtual RAM) is determined by a fixed (base) amount plus a dynamic (growth) amount. The value for the fixed amount is read directly from the PCT. The value for the dynamic amount is based on the amount of memory left over after the fixed allocation and subsequently assigned to each virtual machine based on a per-VM growth factor. Higher growth factors result in a higher proportion of memory given to a VM.

Apart from virtual machines there are many other components that consume RAM, including NVIDIA Virtualization System, auxiliary processors, and protected carveouts. The amount of RAM available to the virtual machine is subject to memory consumed by these components.

The guest_conf struct’s members guest_phys_mem_size and guest_phys_mem_growth_factor describe fields used for guest memory configuration. For example:

A physical CPU or PCPU is a computer system component that executes a serial stream of instructions.

Each instance of a CPU can be considered as a single hardware thread of execution. On a Tegra SoC multiple CPUs are available, manifesting the concept of symmetric multiprocessing (SMP).

A virtual CPU or VCPU is an emulated physical CPU. The operation of a physical CPU can be subdivided into one or more virtual CPUs. Each instance of a VCPU can be considered as a single software thread of execution. Only one VCPU can be executing on a given physical CPU at any time, so multiple VCPUs mapped to one physical CPU are achieved with time-sharing. NVIDIA Virtualization System configuration defines the following configurable attributes for a VCPU:

The vcpu_conf struct describes fields used for VCPU configuration. For example:

This section describes virtual DMA controllers and the PCT syntax for their definition and assignment.

NVIDIA Tegra SoCs support general purpose DMA controllers known as GPCDMA. The DMA controller supports multiple DMA channels. (See the Tegra Technical Reference Manual (TRM) for details.) Each channel can be hooked at runtime to a DMA slave, such as I2C, SPI, or UART. Channels are unidirectional, and two are required for bidirectional use cases.

A virtual DMA controller is analogues to a physical DMA controller with the exception that the number of DMA channels available is less than or equal to total number of channels supported by a physical DMA controller. Each virtual DMA controller is assigned to a virtual machine.

A maximum of eight virtual DMA controllers are supported. The sum of all DMA channels across all virtual DMA controllers must not exceed the channel count supported by the DMA controller.

Virtual DMA controllers comprise the following SoC resources:

Virtual DMA controller configuration describes the virtual DMA controller and assignment of the virtual DMA controller to a virtual machine. The virtual DMA controller is described in terms of the number of DMA channels it supports. The configuration abstracts the low level resources listed above and provides a very simple configuration interface. Internally the virtualized system uses this information to map internal DMA resources to the virtual machine. Configuration is specified in PCT and the Device Tree for the guest OS. Both must remain in sync for correct functioning of the system.

The gpcdma_conf struct’s members chan_start_idx and nr_chan describe the virtual DMA controller in the PCT, as shown in the following example:

The virtual DMA controller presents the exact same interface to the guest as a non-virtualized DMA controller. This enables the guest to use the same device drivers as it would use in a non-virtualized system.

\snippet tegra186-vcm31-p2382-010-a01-00-base-vm1.dts gpcdma dt example

This section introduces the concept of a virtual GPIO controller and explains the PCT syntax to assign GPIO pins to the virtual machine.

The set of physical GPIO pins within any single physical GPIO controller form a physical GPIO domain.

A virtual GPIO controller is a virtual device that behaves the same as a physical GPIO controller except that some of the virtual GPIO pins within the virtual GPIO controller are not implemented. Reads from unimplemented virtual GPIO pin registers yield predefined values, writes are ignored, and all such accesses may cause the virtual machine to encounter a fatal error. Each virtual GPIO controller is said to be mapped to its corresponding physical GPIO controller.

A maximum of eight virtual GPIO controllers are supported per physical GPIO controller, meaning that a maximum of eight virtual machines can access a physical GPIO controller.

The set of virtual GPIO pins within any single virtual GPIO controller form a virtual GPIO domain.

The NVIDIA® Tegra® SoC supports multiple instances of the GPIO controller. Each GPIO controller further has many ports, and each port has a variable number of pins. To facilitate abstraction, all GPIOs are grouped in logical banks (i.e. TEGRA_GPIO_BANK_ID_A, TEGRA_GPIO_BANK_ID_B, and so on). Each bank contains exactly eight GPIO pins.

The NVIDIA® Tegra® TRM expresses the GPIO pins in exactly the same format, which makes it very easy for system integrator to identify GPIO pins.

NVIDIA Virtualization System identifies each GPIO pin using a unique number referred to as GPIO logical pin number. PCT provides a macro to convert a “logical bank, pin” tuple to logical GPIO number:

For simplicity, the GPIO controller is not exposed in the configuration. The virtualized system automatically allocates and assigns a virtual GPIO controller to a virtual machine if one or more GPIO pins belonging to a physical GPIO controller are assigned to a virtual machine.

The guest_gpio_mapping struct’s GPIO member describes the PCT syntax for GPIO pin to VM assignment, as shown in the following example:

No special device tree configuration is required. Make sure that the physical GPIO controller device node is enabled in the guest device tree.

This section describes the concept of a virtual I2C controller, and PCT configuration syntax for defining a virtual I2C controller and assigning it to a virtual machine.

The virtual I2C controller is implemented in software that allows the physical I2C bus to be accessible from multiple virtual machines. The virtual I2C controller implements only a part of the physical I2C bus. This design allows the physical I2C bus to be partitioned between virtual machines. The virtual I2C controller is implemented using a para-virtualization mechanism. NVIDIA Virtualization System implements a Server partition that controls the physical I2C hardware and exposes I2C services using a proprietary interface to the Guest OS I2C driver provided as part of the virtualization system. NVIDIA Virtualization System refers this server partition I2C Server.

An I2C bus can have more than one slave. The system may require distribution of these slaves among virtual machines. In such a scenario NVIDIA Virtualization System allows I2C Server to manage the physical bus and provide para-virtualized access to one or more guest OS.

Configuring I2C is a two-step procedure:

NVIDIA Tegra supports multiple I2C buses. Virtualization System configuration allows any I2C bus to be either directly assigned to the virtual machine as Passthrough peripherals or assigned to I2C Server to allow sharing of the bus and I2C between virtual machines.

Here is an example of PCT configuration:

Virtual I2C Controller Configuration involves two steps:

 

The virtual I2C controller implementation uses the NVIDIA Virtualization System IVC mechanism for low level communication between I2C Server and the guest driver. There is one IVC channel per controller between the server and each guest using I2C Server.

The guest_i2c_mapping struct’s controller, slave, owner, and __padding members contain I2C assignment information. They describe assignment of I2C slaves to the virtual I2C controller. For example:

The Tegra HSP block allows multiple processors to share resources and communicate together. These synchronization elements are reserved for software level inter-processor synchronization and messaging, especially between different ARM processors.

The HSP block encapsulates multiple hardware synchronization primitives:

There are several HSP blocks. Each block is part of one of the CPU clusters.

The HSP instances are:

See the Tegra Technical Reference Manual for the exact number of HSP instances.

Virtual HSP is analogous to the physical HSP block with the exception that it implements a reduced set of synchronization primitives.

The virtual HSP resources are:

The HSP nodes of the VM device tree should have the same interrupt numbers assigned to them in the PCT configuration.

 

Host1x controller provides the standard programming interface to various Graphics, Video engines, and Display. These engines are referred as Host1x clients. Commands are either gathered from a push buffer in memory or provided directly by the CPU, and then supplied to the Host1x clients via host1x channels.

The Host1x channels also provide a means of synchronization between software and any individual engines or amongst the engines themselves via syncpts.

A Virtual host1x Controller works similar to physical access. The difference is that the numbers of available resources are less than or equal to the total numbers supported in physical host1x. Each Virtual host1x is associated with one host1x guest MMIO address space.

NVIDIA Virtualization System Configuration allows maximum of two virtual Host1x controllers per virtual machine. Refer to Two virtual Host1x controller per VM section for more details on the need for two Virtual Host1x instances per virtual machine.

A virtual Host1x controller contains following resources:

Certain host1x engines support sharing between multiple virtual machines, Host1x channel virtualization allows such engines to be accessed via the host1x channel assigned for a virtual machine. Such engines are managed by the RM Server partition.

The following host1x engines support sharing:

Virtual Host1x controller configuration allows parameters to specify the assignment of Host1x engines to virtual Host1x controllers.

Some Host1x engines can only be accessed by one virtual machine and are unable to be shared between virtual machines. Such engines shall be part of only one virtual Host1x controller.

Host1x allows for accessing its engines through host1x channels. Both shared Host1x engines and passthrough-engines engines can be accessed this way by a virtual machine. Due to hardware limitations, it is not possible to have safe access to both engine groups from Host1x channels belonging to the same virtual Host1x controller. To resolve it, in case when a virtual machine owns some non-shared engines (typically VI and NVCSI), it must be assigned two virtual host1x controllers.

First virtual Host1x controller shall manage Passthrough Host1x Engines, GPU syncpoints, display and second virtual Host1x controller shall manage Shared Host1x Engines.

Host1x configuration describes the assignment of host1x internal resources to the virtual Host1x controller, which includes host1x channels and host1x engines accessible using virtual Host1x controller assigned channels.

The exact numbers of channels and syncpoint required for a virtual Host1x controller depend on the use case. Here are a few guidelines:

Refer to the host1x_conf struct’s members channel_pool through high_priority for exact configuration parameters.

Configuration is specified in the PCT and Guest OS Device Tree as shown below. Both must remain in sync for correct functioning of the system.

A virtual GPU is a virtual device and its associated NVIDIA-supplied driver such that the functionality of the virtual GPU is defined relative to a particular physical GPU, where the virtual GPU has the same capabilities as that physical GPU.

A virtual GPU's driver is divided into guest side VGPU driver (specific to different OSes) and RM server. RM server partitions the physical GPU resources and ensures isolation of resources across different guests. It is also responsible for GPU exception handling and recovery. After GPU contexts have been initialized by a guest, GPU work submissions for those contexts are handled directly by the guest.

VGPU is configured in PCT and assigned to a VM. VGPU configuration includes:

For details, refer to the gpu_conf struct.

Example for a dual VM configuration:

The following is an example of RM Server device tree binding:

The following is Guest OS DT binding VGPU node is called "vgpu".

The Audio Processing Engine (APE) is a stand-alone IP that takes care of all the audio needs of Tegra chips with minimal supervision from the CPU. APE contains an audio DSP (ADSP), an internal RAM, an Audio Hub (AHUB) containing many hardware accelerators, a crossbar (XBAR) to connect the hardware accelerators, dedicated DMA engine (ADMA) and a dedicated GIC (AGIC).

The AHUB contains the following hardware accelerators:

Tegra supports a dedicated DMA controller(ADMA) inside the APE to transfer audio data to and from the AHUB. ADMA supports up to 32 unidirectional channels. A Virtual Audio DMA controller allows distributing of ADMA channels between virtual machines. Each Virtual DMA controller is assigned to a virtual machine.

The NVIDIA Virtualization System allows creation of up to 4 Virtual ADMA controllers mapped to the physical ADMA controller hence limiting supported Virtual Machines with audio sharing to a maximum of 4.

The following resources constitute a Virtual ADMA:

Tegra supports a GIC controller inside the APE. All APE interrupts (e.g. ADMA end-of-transfer interrupts) are routed to the Audio GIC (AGIC) controller, which reroutes them to the Legacy Interrupt Controller (LIC) through four interrupt channels (each of FIQ or IRQ type), one per virtual machine.

Virtual AGIC Resources

The virtualization system allows at Max 4 Virtual AGIC Controllers to be mapped to physical AGIC and hence limiting supported Virtual Machines with audio sharing to maximum of four.

The following resources constitute a Virtual AGIC:

Virtual AHUB is implemented using para-virtualization mechanism. The virtualization system implements a server partition that controls the physical AHUB and exposes access to AHUB accelerators using proprietary interface to the Guest Audio driver provided as part of the virtualization system. The virtualization system refers this server partition as Audio Server.

This section describes the configuration mechanism.

Overall configuration is done at two places and both must be kept in sync.

The ape_conf struct’s APE configuration members, is_adsp_enabled through num_adma_irq_routed, describe the Virtual Audio Configuration Parameters in PCT.

The following example defines the APE configuration for a configuration with two virtual machines.

Virtual machine 1 configuration:

Virtual machine 2 configuration:

Virtual Audio presents same device tree nodes as non-virtualized audio with some nodes with a different compatible strings to make the driver virtualization aware. In addition to existing nodes, Virtual Audio adds a new tegra-virt-alt node.

The following sections described two types of Audio Server configuration supported by the APE: PCT based configuration and AHUB based configuration.

You can modify the PCT to override the Audio Server’s default configuration.

Refer to guest_config.h in the PCT directory for the OS configuration you are using, e.g. linux-qnx. This usually defines the guest configuration. The ape_cfg structure in guest_config.h defines the audio configuration for each VM. The structure is defined in the pct.h header file, which is in the Foundation PDK at:

The structure definition looks like this:

Refer to the sound_ref DT node in the Linux Board DT flashed for the particular configuration.

The sound_ref node is added to the DT file for passing platform related data for APE AHUB configuration.

The bitclock-slave, frame-slave, format, bitclock-noninverstion, and frame-noninversion nodes configure the I2S controller’s I2S/TDM format and master/slave mode. Use the bclk-ratio property to configure the I2S bit clock sample rate. The srate and num-channel properties indicate I2S LRCK and the number of channels in one frame.

The elements of an I2S property are:

On code-name Parker devices the APE supports four AMXs and four ADXs. The device tree properties nvidia,num-amx and nvidia,num-adx indicate the total number of AMXs and ADXs to be registered. The nvidia,amx-slot-size and nvidia,adx-slot-size nodes indicate the slot map size of each AMX or ADX, which is related to the size of nvidia,amx-slot-map and nvidia,adx-slot-map.

As the following diagram shows, an AMX can multiplex data from up to four input streams, each containing up to sixteen 32-bit audio channels, into one output stream with up to sixteen 32-bit channels, forming a TDM signal. An ADX can demultiplex any signal multiplexed by an AMX.

A frame in the multiplexed output stream may be up to 64 bytes long, so it can hold up to 16 slots of 32 bits each. Thus an AMX can multiplex up to 16 of the input frame’s 64 channels into the output frame.

The AMX can map any byte in the input frame to any position in the output frame, though, so it is not limited to multiplexing complete 32-bit channels. For example, by mapping only the two high-order bytes of each input channel, it could multiplex up to 32 channels of 16 bits each into the output frame.

The mapping of input frames to output frames is controlled by a slot map which consists of up to 64 entries, one for each byte in the output frame. Each entry identifies one byte from the input frame and maps it to the corresponding byte in the output frame. That is, the first entry maps an input frame byte to output frame byte 0, the second entry maps an input frame byte to output frame byte 1, and so on.

The TDM_SLOT_MAP macro defines slot map entries in the device tree. It defines a slot map entry as a four-byte bit map:

Where:

Audio Server converts the device tree’s slot map to a hardware slot map that the AMX and ADX can use. The next diagram shows the structure of the hardware slot map.

Each entry in the hardware slot map is one byte long, and contains:

For example, the following TDM_SLOT_MAP macro defines a slot map entry that maps byte 2 of input stream 3, channel 4:

It generates this entry in the device tree slot map:

When Audio Server converts the device tree slot map to the hardware slot map, it generates this entry:

Note that the TDM_SLOT_MAP macro and the device tree slot map count the channel number from 1, but the hardware slot map counts it from 0. In the example, the TDM_SLOT_MAP macro and the device tree slot map reprsent channel 4 by the value 5, but the hardware slot map represents it by 4 (0b0100).

Here is an example of a definition of a complete device tree slot map:

The number of channels, input bits, and output bits for each module can also be configured separately for each of the input/outputs in that module. The format of a configuration entry is:

Where:

For example:

You can use device tree configuration to change the clock source for an I2S controller. The node skeleton below shows a typical I2S controller node that defines a clock property:

By default, an I2S controller in master mode has a clock source configured for the pll_a_out clock. To change the I2S controller clock source, override the clocks property in the platform-specific DTS file. You only need to update the <parent> and <parent_sync> elements in skeleton shown above.

Possible values for <i2s> are:

Possible values for <parent_sync> are:

As an example, the default I2S1 configuration look like this:

To derive the I2S1 controller clock from the I2S3 clock, we would define this node in the platform device tree:

The storage partitioning mechanism in virtualization is an extension provided to the native storage configuration via flashing .cfg files.

This section describes the additional parameters added to the flashing configuration file to support storage partitioning specific to virtualization, and the configuration required for partitioning storage media between multiple guest operating systems.

The following example code is from DRIVE CX (P2382) Dual-Linux configuration.

See foundation/meta/pct/p2382-t186/linux-linux/platform_config.h for the complete PCT setting.

For more details on mempool & IVC configuration refer to PCT chapter.

Every virtualized partition must have the virtual_storage_ivc_ch attribute. The VSC server relies on this attribute to configure the layout of storage partitions.

The following table describes the virtual_storage_ivc_ch attribute bitfield.

The following example, extracted from foundation/meta/pct/p2382-t186/linux-linux/global_storage.cfg shows the usage of virtual_storage_ivc_ch. There are two virtualized partitions in the example.

In the first virtualized partition, gos2:

The mempool ID and IVC queue ID of virtual_storage_ivc_ch attribute specify that this partition belongs to the guest OS or vm server where they are defined in the platform configuration file foundation/meta/pct/p2382-t186/linux-linux/platform_config.h, as shown in the following example:

According to the above IVC queue and mempool settings, the gos2 partition belongs to Linux VM2.

In the second virtualized partition, gos1-mmc:

The mempool ID and IVC queue ID of the virtual_storage_ivc_ch attribute specify which guest or VM server this partition belongs to. They are defined in the platform config file foundation/meta/pct/p2382-t186/linux-linux/platform_config.h as shown in the following example:

According to the above IVC queue and mempool settings, the gos1-mmc belongs to Linux VM1.

The tegra_hv_storage device node is added to the device tree of the guest OS to declare virtualized storage. In the example configuration described in the previous sections, gos2 belongs to Linux VM2 and gos1-mmc belongs to Linux VM1. The next step is to declare the partitions in the guest device tree.

The corresponding device nodes are reported to Linux VM1 in the device tree (Linux/hardware/nvidia/platform/t210/vcm/kernel-dts/tegra210-vcm31-p2382-0000-a00-00-vm1.dts) as shown in the following:

The IVC and mempool attributess must match the corresponding setting the platform config file foundation/meta/pct/p2382-t186/linux-linux/platform_config.h. The IVC queue must be <66> and the mempool must be <6> for Linux VM1.

The corresponding device nodes are reported to Linux VM2 in the device tree (Linux/hardware/nvidia/platform/t210/vcm/kernel-dts/tegra210-vcm31-p2382-0000-a00-00-vm2.dts) as shown in the following example:

The IVC and mempool attributes need to match the corresponding setting in the platform config file at foundation/meta/pct/p2382-t186/linux-linux/platform_config.h. The IVC queue must be <67> and the mempool must be <7> for Linux VM2.

The VSC architecture allows multiple guests to boot from the same storage. The Partition Loader and OS Loader both have client drivers for communicating with the storage server.

The following is an example showing how to create boot stack partitions in the same storage for two guest OSes:

Partition gos1 is the boot partition of Guest1 (partition_attribut=1) and the guest storage configuration file is linux_storage.cfg.

In the following example, the configuration PL/OSL uses IVC queue 0x58 and IVC mempool 0x8 to to communicate with the VSC server to access this partition:

Partition gos3 is the boot partition of Guest3 (partition_attribut=3) and the guest storage configuration file is android_storage.cfg. The configuration PL/OSL uses IVC queue 0x5C and IVC mempool 0x9 to communicate with the VSC server to access the partition.

Inter-VM Communication (IVC) is used to facilitate information exchange between two VMs over shared memory. The underlying shared memory format consists of a pair of circular FIFO buffers, one for each direction. To avoid the need for polling, a virtual interrupt implements signaling on special state transitions.

The pct_ivc_config structure’s mem_size, irq_start, irq_size, queues, and mempools members configure inter-VM communication.

The System Trace feature records events which the System Profiler (SP) application can display in a timeline view. For HV events, the size of the buffer, as well as the type of events recorded, are configurable through the PCT.

The platform_conf structure’s log_size and trace_mask members configure the Hypervisor log buffer.

The guest_conf structure’s log_access member configures access to the Hypervisor log buffer.