CPU Configuration

To view or change the current virtual machine CPU configuration, select CPU in the Device column of the left-hand pane.

This will open the CPU configuration screen. The image below shows the Charon-4U configuration screen as an example:

The following table lists each of the fields in the CPU configuration window and describes their use.

Virtual machine CPU configuration fields
Field	Description
Hyper-threading checkbox	Enable the Charon-SSP adaption for a hyper-threading host environment or for running the Charon host under a Hypervisor. With this mode enabled, Charon-SSP does not set a CPU core affinity on the host system, but relies on the scheduler of the host operating system instead. Power option Power save will allow idle guest system CPU threads to be rescheduled.
Number of CPU	Configure the number of virtual SPARC CPUs. Supported number of CPUs: Charon-SSP/4M: 1 to 4 virtual SPARC CPUs Charon-SSP/4U(+): 1 to 24 virtual CPUs Charon-SSP/4V(+): 1 to 64 virtual CPUs
Power options	This option determines the host CPU behavior when the guest Solaris is in idle state. Performance Choosing this option keeps the host CPU in a busy loop waiting for next Solaris activity. This option offers the best response time in Solaris but the host CPU usage is at 100% all the time. Balanced (default) Choosing this option allows the host CPU to go into an idle state until the next Solaris activity. This option offers a good balance between Solaris response time and host CPU usage. Power save The host CPU is in deep “sleep” mode when the guest Solaris is in idle state. With this option and hyper-threading mode set, an idle Solaris guest system CPU thread can be rescheduled.
CPU binding	Assign specific host CPUs to the processing of SPARC instructions. If configured, each virtual SPARC CPU must be assigned to exactly one host CPU for instruction processing. This field consists of a comma-separated list of CPU IDs (index starts from 0). If left blank, the virtual machine software will assign affinity itself starting with the highest CPU ID (recommended). Cannot be used with hyper-threading mode enabled. CPU cores assigned to emulated CPUs are never shared between instances.
I/O binding	Assign specific host CPUs to the processing of virtual machine I/O requests. This field consists of a comma-separated list of CPU IDs. If left blank, the virtual machine will assign I/O processing affinity itself starting from CPU ID 0 (recommended). CPUs listed here cannot be shared between instances. If there is an overlap with manually configured bindings in other instances or the automatically calculated I/O CPU allocations, the instance will not start with the message: “`Wrong IO affinity setting: already allocated by another thread.`”
Reserved I/O CPUs	Reserve a number of CPUs on the host system for processing virtual machine I/O requests. Allocation will start from the lowest CPU ID. If neither I/O binding and Reserved I/O CPUs are set, then the virtual machine software assigns 1/3 (minimum 1; rounded down) of the number of host CPU cores to I/O processing starting from the lowest CPU ID (recommended). If there is an overlap between a manual configuration in one instance and the automatic calculation of I/O CPUs in other instances, overlapping I/O CPUs are shared between instances. If the number of I/O CPU cores (configured or calculated automatically) + the number of emulated CPUs is higher than the number of available host CPU cores, the following error is logged and the emulator does not start: "`Wrong CPU affinity setting: no enough host CPUs.`"

Please note:

Manual I/O CPU bindings can be used to optimize I/O and DIT performance on a host system running multiple Charon-SSP instances, because it allocates dedicated I/O CPU cores to a system (no sharing).
Manually configuring the number of reserved I/O CPUs can be used to adjust the CPU pool used for I/O operations. Overlapping CPU cores between several instances will be shared.
Once any manual configuration is used, its influence on all concurrently active Charon-SSP instances must be considered in order to avoid performance degradation.