Contents

Overview

The hardware of the emulated system is defined in the emulator configuration file. Charon-PAR comes with a number of template files that are stored in /opt/charon/cfg. Each template file contains the settings for a particular Charon-PAR/PA3 or Charon-PAR/PA9 hardware model or model family. The files also contain important descriptions for all parameters listed.

The name of the Charon-PAR/PA3 template file is  pa3.cfg. The names of the Charon-PAR/PA9-64 templates are rp*.cfg, for Charon-PAR/PA9-32 pa9-32.cfg.

Before starting an emulator instance, 

• copy the appropriate template file to the directory where you store the configuration data of your emulator instance, and
• modify the template file according to your requirements.

Comments in the file are preceded by the # character.

Please note that some entries require an equal-sign (=) and for other parameters an equal-sign is not allowed. The emulator will not start if a required equal-sign is missing or an equal-sign is placed where it is not permitted.

If a parameter value is a string, it must be enclosed in double quotes.

The configuration file is structured in several sections that are described below.

Please note the following if running the emulator in a cloud enviroment: some emulated hardware can be linked to physical host hardware. For example, serial lines, tape drives, optical drives. These options are not available in a cloud environment as the physical devices do not exist there.

License Configuration

This section defines the license specific parameters.

Parameter license_key_id 

Optional parameter for HASP licenses, mandatory for VE licenses.

Please note: when configuring the emulator, VE licenses and HASP licenses are mutually exclusive. If a configuration file contains the definition of a VE license, any HASP license definition is ignored (that is, the VE configuration takes precedence).

Parameter Use for HASP Licenses

There can be several license_key_id parameters in this section. They define a prioritized list of license keys. The first entry has the highest priority. If no key with this ID is available, the next key in the list will be tried. If a higher priority key becomes available, the emulator will switch to this license at the next periodic license check.

Syntax:

license_key_id "key-id-prio1"

license_key_id "key-id-prio2" 

(...)

Parameters:

The key-id-prioX parameter is a numerical value that can be determined using the hasp_srm_view -all command and identifying the value of the License KeyId parameter in the output. As long as the ID is a numerical value, the quotes are optional.

Parameter Use for VE Licenses

The configuration of primary and (optionally) backup license server must be entered into the emulator configuration file using a text editor.

Relevant parameter:

license_key_id "VE://<license-server-IP>[:<port>]/<passphrase>/"

Where the following parameters are used:

• license-server-IP: the IP address of the VE license server (127.0.0.1 if the VE license server is on the same host).
• port: the TCP port on which the license is served (if not specified, the default port 8083 will be used).
• passphrase: the passphrase of the correct product section on the license. This is required for the emulator to identify the correct section.

To configure a backup license server, repeat the line, but with the address and passphrase of the backup license server. The first line is treated as the primary server, the second as the backup server.

Parameter license_use_any_key 

Please note: this parameter is not supported by the VE license server. If it is in the configuration file, comment it out.

Optional parameter for HASP licensing. This parameter is closely related to the license_key_id parameter. If the license_key_id parameter is used, it determines what happens if none of the defined license keys are available.

Syntax:

license_use_any_key false | true 

Parameters:

Default value: false

If this parameter is set to true, the emulator will try to find any other suitable licenses should none of the licenses specified by the license_key_id parameter(s) be available. By default, if the license_key_id parameter is used, only the license keys specified there will be considered.

Parameter license_id

Please note: this parameter is not supported by the VE license server. If it is in the configuration file, comment it out.

Optional parameter for HASP licensing. There can be several license_id parameters in this section. They define a prioritized list of product license IDs. The first entry has the highest priority. If no key with this product license ID is available, the next product license ID in the list will be attempted. If a higher priority license becomes available, the emulator will switch to this license at the next periodic license check.

Syntax:

license_id "lic-id-prio1"

license_id "lic-id-prio2" 

(...)

Parameters:

The lic-id-prioX parameter is a string value that must be enclosed in quotes. It can be determined using the hasp_srm_view -all command and identifying the value of the Product License Number parameter in the output. If none of the specified product licenses is available, the emulator will not start, or a running emulator will stop.

Problem Handler Parameters

The Charon-PAR configuration file supports the following parameters that can be used to alert the user to potential license problems:

Machine State Parameters

Optional parameter: allows a non-default path to store the machine state.

Syntax:

machine_state_path "path"

Parameters:

The value of path is a Unix file system path. It must be enclosed in double quotes.

System Model Configuration

The system model configuration section contains one parameter defining the emulated historic PA-RISC model.

Syntax:

model "model-name"

The configured model must be covered by your license.

Charon-PAR Model Names

Model Name Rules

Charon-PAR/PA9-64 model name details

The model names of Charon-PAR emulated historic PA-RISC systems for HP-UX consist of three parts:

<family-name>-<number-of-cpus>-<clock-speed>

Parameters:

• family-name describes the model family, e.g., rp2400,
• number-of-cpus describes the number of emulated CPUs, and
• clock-speed describes the CPU clock frequency in MHz.

Example: rp2470-2-750 stands for an rp2470 model with two 750-MHz CPUs.

Abbreviations are possible, e.g,, rp2470-1 stands for an rp2470-1-750 model. See configuration file templates for permitted abbreviations.

Charon-PAR/PA9-32 model name details

Currently, there are the following 32-bit models:

• The PA9-32/720 (PA-RISC v1.1a) with single CPU at 50MHz, model string: "720"
• The PA9-32/B132L with 1 CPU at 132MHz (oversized models with up to 16 CPUs may be available), model string: B132L-<nr-of-cpus>.
  Supported starting with Charon-PAR 3.0.7.

Model Name Examples

Each configuration file template is preconfigured for a certain family of models. The following table shows a sample model-name for each of the configuration file templates:

⁽¹⁾ The rp3440 and rp4440 models may also be available in “oversized” versions up to 128 CPUs and 512GB RAM. Please check the availability for your model with your Sales representative. The +-versions of the rp34xx and rp44xx models emulate PA-8800 CPUs, the non-plus versions PA-8900 CPUs.

⁽²⁾ Starting with version 3.0.5, the models above may also be available in “oversized” versions up to 64 CPUs and 512GB RAM. Please check the availability for your model with your Sales representative.

Memory Configuration

This section defines the RAM size for the emulated system. It only contains one parameter.

Syntax:

memory memsizeG
   or
memory memsize


Memory size can be specified in gigabytes (denoted by the letter G) or megabytes.

Parameters:

Default memsize: 2 gigabytes

Maximum memsize: maximum allowed RAM size for the emulated system. See section Emulated Models Supported by Charon-PAR for the maximum allowed values.

The configurable memory also depends on the amount of memory available on the host system.

I/O Slot Configuration

This section is used to load additional controllers for the emulated system.

The available expansion PCI slots depend on the configured hardware model (see configuration template files and chapter Emulated Model Hardware Configuration Details). The Emulated Model Hardware Configuration chapter also lists the device paths for all expansion slots of a model. 

Supported controller types: SCSI controllers and Ethernet cards.

Syntax for Ethernet cards:

load ETH tulip PCI slot-number

Parameters for Ethernet cards:

The parameter slot-number identifies the number of PCI slot (see configuration file template and Emulated Model Hardware Configuration Details). All other parameters are fixed in the current version of the software.

Syntax for SCSI controllers:

load SCSI controller-model PCI slot-number

Parameters for SCSI controllers:

• slot-number identifies the number of PCI slot (see configuration file template and Emulated Model Hardware Configuration Details).
• controller-model can be
  53C875 for single-chip boards (assigned to PCI device function 0), or
  53C896 for a dual 53C895 controller (assigned to PCI device function 0 and 1)

System Console and Serial Line Configuration

Built-in Serial Lines

Most of the emulated systems have 2 serial lines. Please refer to Emulated Model Hardware Configuration Details for the device path associated with the built-in serial lines.

The configuration path string is used in the configuration file to specify parameters for the virtual serial line.

Super/IO Module

If the Super/IO module has been loaded, there are two additional serial lines. In the configuration, they are identified by superio_001.uart0 and
superio_001.uart1. The basic configuration options are the same as for the default serial lines.

Configuration Syntax

Syntax:

serial.uartX.device.<option>="<value>"

or

superio_001.uartX.device.<option>="<value>"

The options available for configuration are described below.

Serial port options

type

The type option specifies the serial line connection type.

Possible values:

port

The format and values of the port option, depend on the type of the port.

command

This parameter is optional. It can be used to specify a terminal emulation program that is started automatically when the emulated system is started. Charon-PAR provides preconfigured profiles for PuTTY (PAR-Socket, PAR-Telnet, PAR-Telnet-VT100) that can be used to connect to the emulated system via a serial line.

stop_command

Boolean flag. If true, the command started on the serial line (parameter command) will be stopped when exiting from the emulator.

out_log

File name for logging the output character stream from the CPU to the device. Does not depend on the port being operational (the actual transmission is not logged). Depending on the data sent, the file may best be viewed using a tool such as hexdump or od.

in_log

File name for logging the input character stream from the port to the device. Best be viewed using a tool such as hexdump or od.

keep_on_reset

New in version 3.0.6. For physical serial ports. If set to 1, the emulator will keep the port speed, parity, stop bits, data bits on reset.

port_defaults

New in version 3.0.6. For physical serial ports: string defining the port default settings after a reset.

The format of the string is <speed> <bits><parity><stop> with the following possible values:

• speed: 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, or 115200 
• bits: 5, 6, 7, or 8 
• parity values and the corresponding stty parameters:
  
  • N: -parenb (none)
  • E: parenb -parodd -cmspar (even)
  • O: parenb parodd -cmspar (odd)
  • M: parenb -parodd cmspar (mark)
  • S: parenb parodd cmspar (space)
• stop values and the corresponding stty parameters:
  • 1: -cstopb (one stop bit)
  • 2 : cstopb (two stop bits)

Example: system.uart0.device.port_defaults = "115200 8N1"

Console Communication

Charon-PAR provides preconfigured PuTTY session templates for connecting to a serial emulator console port. The templates must be copied to /root/.putty/sessions or /root/.config/putty/sessions because the emulator must be started as the root user.

Method 1: TCP port 30000, raw data mode

serial.uart0.device.type="socket"
serial.uart0.device.port=":30000"
serial.uart0.device.command="putty -load PAR-Socket"

Method 2: TCP port 30000, Telnet protocol

serial.uart0.device.type="telnet"
serial.uart0.device.port=":30000"
serial.uart0.device.command="putty -load PAR-Telnet-VT100"

To connect to the console port without loading a PuTTY template, the command parameter can be set to

serial.uart0.device.command="putty"

To start the xhpterm emulator (Charon-PAR/PA3), the following setting should be used:

serial.uart0.device.command="./xhpterm -port 30000 -clean -font 10x20"

Please note::

• If no command is specified, a connection to the TCP port is possible by starting another terminal emulator manually.
• For device naming on Charon-PAR/PA9-32 refer to the serial line configuration section above.
• By default, pressing Ctrl+C in the Charon-PAR console is passed to the emulator's child processes and kills the PuTTY console process. If this is not desired, you can modify the command line to include the setsid command to start the telnet command in a new session.
  For example: serial.uart0.device.command="setsid putty -telnet -P 30000 localhost"


SCSI Controllers and Devices

Every Charon-PAR emulated model has preconfigured SCSI controllers that can be used to configure emulated disks for the guest system. All models also have the option to load additional controllers. Please refer to the section I/O Slot Configuration in this chapter.

Please note:

• The description below shows how to work with preloaded SCSI controllers. Once an additional SCSI controller has been loaded, the steps below also apply to such a controller.
• It is not recommended to place emulator storage devices (in particular vdisks) on NFS as this will have a significant impact on performance. However, if any of the storage (e.g., ISO files or vdisks) is on an NFS share, NFS locking must be enabled and all intermediate firewalls between client and server must allow the port used by the lockd and statd. Failure to do so will cause the emulator to hang at startup.

Preloaded SCSI Device Controllers

Charon-PAR implements I/O using controllers. Each controller

• supports up to 15 SCSI devices,
• is identified by a character code,
• is assigned a path corresponding to the leading for elements of the device path.

The tables below show the preconfigured SCSI controllers of an rp2400 model as an example.

Please note: Other models may have more or less preconfigured controllers with different device paths and code mappings. For details regarding your model refer to the configuration file template or the chapter Emulated Model Hardware Configuration Details.

Load Device Command for SCSI Devices

The load command is used to define SCSI devices.

Syntax:

load DDXnnn

DDXnnn represents the device name. It has the following components:

Examples:

To load a disk on device path 0/0/1/0.1.2 (SCSI target ID 1, LUN 2), add the command

load DKA102

To load a tape on device path 0/0/1/1.12.0 (SCSI target ID 12, LUN 0), add the command

load MKB1200 

The image Subcommand

After a SCSI device has been loaded, the associated container file or device must be specified. Please note: physical tape or CD-ROM drives are not available in cloud environments.

Please note: the image subcommand is for MK and DK devices only.

Format:

device.image="<path-to-device-or-file>"

Parameters:

• device: the virtual SCSI device created by the load command. See the load command for details about the device name syntax.
• path-to-device-or-file: the path to the Linux device (a physical disk device or disk partition) or container file. For physical devices it is strongly recommended to use a persistent device name from
  • /dev/disk/by-id, or
  • /dev/disk/by-uuid
    instead of a non-persistent /dev/sdX device name.

Example:

To associate a disk device on 0/0/1/0.0.0 (controller code A, SCSI target ID 0, LUN 0) with a container file called ldev1.dsk, add the command

DKA0.image="ldev1.dsk"

The devname Subcommand

Use the devname subcommand to specify the device to be used for a generic SCSI device (GK device). Please note: physical tape or CD-ROM drives are not available in cloud environments.

Please note: A generic SCSI device can be a tape or disk device. Guest system SCSI commands are passed through to the device directly and not handled by the Linux disk or tape driver. The functionality depends on the device understanding the guest system SCSI commands.

Format:

GKXnnn.devname="<path-to-device>"

Parameters:

• GKXnnn: the generic virtual SCSI device created by the load command. See the load command for details about the device name syntax.
• path-to-device: special filename of the generic SCSI device (/dev/sgX) on Linux, for example: /dev/sg0.

Tape autoload Subcommand

To enable tape container files to be automatically loaded as tapes into a virtual tape device, the autoload command can be added for a specific tape device in the configuration file. Not applicable to physical tape devices.

Format:

MKXnnn.autoload=yes|no

Parameters:

MKXnnn: the emulated tape device. Possible values for X and nnn see above.

Default: autoload is off by default.

Please note:

• The autoload command works well in many situations but can cause problems in some cases, for example with multi-volume backups. Any applications using tape devices should be tested thoroughly to verify if the autoload option is working as expected.
• MPE/iX can load a tape using operating system utilities. HP-UX cannot. Hence, the autoload command may be more often useful in an HP-UX environment.

Tape size Subcommand

The size command limits the maximum size of a tape container file. Not applicable to physical tape devices.

Format:

MKXnnn.size=<size-in-bytes>

Parameters:

• MKXnnn: the virtual SCSI tape device created by the load command. See the load command for details about the device name syntax.
• size-in-bytes: maximum size of the tape container file.

Default: tape container file size is not limited.

Tape Subcommands for Physical Tape Devices

The following two commands can only be used for physical tape devices:

Typical System Disk Configuration

The system disk is usually configured on device path 0/0/1/0.0.0. To load this device and to map it to a disk image file, add the following commands:

load DKA0

DKA0.image="/data/virtual-disks/ldev1.dsk" 

Network Card Configuration

General information

The emulated Ethernet interfaces of Charon-PAR can be linked either to a

• physical host interface,
• a TAP interface connected to a virtual bridge on the host, or
• (since Charon-PAR 3.0.9) a MACVTAP interface linked to a physical NIC on the host.

Notes for physical interfaces:

• If used directly as a guest interface, offloading parameters must be turned off using the initialization command parameter in the configuration file.
• In cloud environments, the necessary interface settings are not always reflected correctly on the cloud-provided NICs. For such installation settings a MACVTAP interface can be used to provide a dedicated connection without connecting the emulator directly to the physical interface.

Notes for TAP interfaces:

• A TAP interface can either be created by the user or will be created automatically by the emulator if it does not already exist.
• For automatically created TAP interfaces, the user can specify a name or let the emulator select a name.
• A automatically created TAP interface is not automatically added to a bridge, this must be configured via the initialize_command (see the Ethernet Configuration Parameter table below).
• An automatically created TAP interface is deleted automatically upon emulator stop.
• If used in a cloud environment, only internal virtual bridges (no connection to the cloud LAN) are supported.

Notes for MACVTAP interfaces:

• Introduces a transparent bridge interface associated with on physical NIC on the host, and provides a dedicated interface to the emulator.
• Provides an abstraction layer between physical NIC and emulator.
• Physical interface requires no changes in the offloading configuration.
• Fragmentation is performed by Linux on the MACVTAP interface. Jumbo frames on the physical interface will not cause problems.
• Uses same MAC address as the physical interface.
• Suited for associating a dedicated host Ethernet interface to the emulator in cloud environments.

Notes for network configurations on VMware:

• ESXi has configuration parameters that improve security but may block certain emulator NIC configurations.
• One configuration option allows or blocks promiscuous mode (the default mode of operation for Charon-PAR guest NICs).
• Other configuration options allow or block the change of a MAC address or the use of a different, additional MAC address on the same NIC (MAC address changes, Forged transmits).

By default, emulated models have one Ethernet device. Depending on the model, more Ethernet devices can be added.

A guest HP-UX system will perceive the network card as a 10/100 Mbit/s controller running at 10 Mbit/s half-duplex. If the user tries to change this setting using SAM or the lanadmin command, the command will be accepted but the displayed interface settings will not change.  However, the throughput of the emulated network card depends on the combination of network performance, physical network card characteristics, host system and guest system performance - it is not tied to the displayed interface settings. So the actual throughput will be what can be achieved depending on the conditions listed above.

The emulated network devices

• DE 500 PCI based cards (for 64-bit systems), and

• LASI-82596 cards (for the 32-bit system)

do not support Jumbo frames. For physical interfaces, this feature must be disabled in the emulator configuration (together with any other offloading parameters) using the initialize_command parameter.

Ethernet Card Device Names

Names on 64-bit systems:

The name of the Ethernet interface in the emulator configuration file has the format EWxn with the following definitions:

• x is an uppercase letter starting with A for the first interface and then continues with B, C, etc. for additional interfaces. The possible number of network cards depends on the features of the original physical system. The absolute maximum number is 16.
• n is the device number of the card starting with 0 for each value of x.

Names on 32-bit systems:

The currently supported 32-bit system supports only one Ethernet card:

• Model 720: system.lan0.card
• Model B132L: gsc.lasi.lan.card

Ethernet Configuration Parameters

This section lists the available Ethernet interface configuration parameters.

Basic syntax:

<device-name>.<parameter>="<value>"

The device-name specifies the name of the Ethernet card as described above in the Ethernet Card Device Names section. 

The parameters and their values are described in the following table:

Logging configuration

This section defines how Charon-PAR handles logging. Note that the default log file location is the directory in which the emulator was started.
This can be changed with the emulator command-line option -l (or --logfile-path).

Log File Parameters

The following table shows the parameters relevant to the log file and their values:

Log File Format

Starting with version 3.0.1 the log file has the following format:

YYYYMMDD:hhmmss.uuuuuu:<severity><message>

   where

YYYY   - year
MM     - month
DD     - day
hh     - hour
mm     - munites
ss     - seconds
uuuuuu - usecs

<severity> := '(warn|err|ERR):' or empty

warn   - warning
err    - error
ERR    - fatal error

<message> the component's message in free form

Parameter system.license_logging_level

Starting with Charon-PAR version 1.11, periodic (once per hour) log messages indicating a successful periodic license check are disabled by default to avoid cluttering the log file. They can be re-enabled by adding this parameter to the emulator configuration file.

Syntax:

system.license_logging_level = value

Parameters:

• If value is set to 2, the messages are enabled.
• If value is set to 0 or 1, the messages are disabled.

Please note that this parameter must be placed towards the end of the configuration file and will not work if placed before the memory configuration.

SuperIO Configuration

General Information

The SuperIO module is included in the Astro chipset and emulates a PCI board with PC style peripherals used in historic 64-bit PA-RISC systems:

• parallel port
• 2 serial ports
• dual-channel IDE controller
• floppy disk controller
• USB controller
• timer
• PIC interrupt controller

The current version of Charon-PAR supports only a subset of these devices. And the SuperIO module is only supported on models that are based on the Astro chipset (rp24xx and rp54xx).

Currently supported are (depending on support by the emulated model and guest operating system)

• two serial ports
• one parallel port

Loading the SuperIO device

Before any devices of the module can be configured  and used, the module must be loaded in the emulator configuration file.

The SuperIO module can be loaded in any system model with PCI bus support.

Use the following syntax to load this module into a slot on the default bus:

load SUPERIO sio <bus-number> <slot-number>

Example:

load SUPERIO sio 0 6

Use the following syntax to load this module into an PCI expansion slot:

load SUPERIO sio PCI <slot-number>

where the slot number is the number listed in the configuration file template or in Emulated Model Hardware Configuration Details for the expansion I/O slot selected.

Please note:

• Only one SuperIO module can be loaded in the configuration. Multiple SuperIO instances will not work properly.
• The usable bus numbers and slot numbers depend on the emulated model and the already loaded devices.
• If another PCI device is already installed in the specified PCI slot, the load command will fail with an error message.
• The correct bus/slot location of the device is important to preserve the correct GSP (service processor) console configuration:
  • If the SuperIO module is inserted in a slot before the normal system serial console, the service processor console (GSP console) is set to the first SuperIO serial port.
  • HP-UX does not support the SuperIO serial port as GSP console. With such a configuration, it will crash early-on in the boot process. Therefore, take care to always use a slot number higher than the one where the correct system console line has been loaded.

After booting the guest HP-UX system, the example above will result in an ioscan output similar to the following:

ba          1  0/0/6/1      superio   CLAIMED     BUS_NEXUS    PCI Core I/O Adapter
tty         1  0/0/6/1/1    asio0     CLAIMED     INTERFACE    Built-in RS-232C
tty         2  0/0/6/1/2    asio0     CLAIMED     INTERFACE    Built-in RS-232C
ext_bus     4  0/0/6/1/3    SCentIf   CLAIMED     INTERFACE    Built-in Parallel Interface
unknown    -1  0/0/6/1/4              UNCLAIMED   UNKNOWN      Built-in Floppy Drive

SuperIO Serial Ports

Serial ports installed on SuperIO module can be configured the same as other serial ports. Please see chapter Serial Line Emulation Notes for more information.

Path names for serial devices in the emulator configuration:

• superio_001.uart0 - COM0 port
• superio_001.uart1 - COM1 port

Serial ports configuration example:

superio_001.uart0.device.type="telnet"
superio_001.uart0.device.port=":30001"

superio_001.uart1.device.type="telnet"
superio_001.uart1.device.port=":30002"

SuperIO Parallel Port

The parallel port installed on a SuperIO module connects to the host system parallel port device /dev/parport0. The parallel port output from the guest OS is redirected to the host parallel port. No additional configuration for the parallel port is required.

However, it may be necessary to install the required kernel drivers in HP-UX and rebuild the kernel to activate the interface.

If the ioscan command shows the parallel port as UNCLAIMED, perform the following steps:

1. Use the kcmodule command to verify the status of the required drivers:
   # kcmodule |grep CentIf
CentIf static explicit
SCentIf static explicit


2. If the status is unused, load the modules into the kernel using the commands:
   # kcmodule CentIf=best
# kcmodule SCentIf=best


3. You will be informed that this change can only become active after the next reboot. If you confirm, the kernel will be modified and you can reboot the system.

Once the ioscan command shows that the parallel port as CLAIMED by the correct driver, you can, for example, use SAM to configure a printer on the parallel port
(Printers and Plotters > LP Spooler > Printers and Plotters > Action > Add Local Printer > Add Parallel Printer). On HP-UX 11.31, use SMH for this task. Please note that at the time of writing SMH only worked with the emulator when being used over the network (not on the serial console).

If no parallel port device exists on the host system, an error message similar to the one below will be printed to the emulator log. It does not affect system operation, but the parallel port redirection will not work.

err:open('/dev/parport0', O_RDWR) is failed (errno 2) No such file or directory
err:ioctl(handle, PPCLAIM) is failed (errno 9) Bad file descriptor

Modern host systems often have no physical parallel port. In such cases, a USB-LPT adapter or a software redirector (such as LPT-over-IP) can be used. The emulated parallel port operation depends on the host parallel port operation and some USB-LPT adapters may not produce reliable results.

Other Parameters

Parameter system.do_timer_correction

If the system time of the emulated system deviates too much from the correct time, it can cause application problems in the emulated system. If this cannot be solved by other means (e.g., NTP), the parameter described here can be used to adjust the system time of the emulated system based on the host system's NTP adjusted time.

Syntax:

system.do_timer_correction = false | true

Parameters:

If set to false, no time correction will take place.
If set to true, the time of the emulated system will be corrected as described above.

Default: false

Parameter fma_check

Charon-PAR requires a host CPU that supports the FMA capability. Normally, an emulator will not run when trying to start it on a CPU without the required capabilities. 

This parameter allows you to disable the FMA check. However, this may lead to unexpected problems with the guest operating system.

Please note: Do not use this parameter if you run PA9 instances. For PA3 instances, use the configuration option at your own risk.

Syntax:

fma_check = false | true

Parameters:

If set to false, Charon-PAR will not check the FMA support of the host CPU.

Default: the check is enabled.

Parameters system.stop_on_halt and system.stop_on_halt_timeout

These parameters are applicable to emulated systems in which a HP-UX guest operating system runs.

When HP-UX is shut down with the shutdown -h command, the guest system will be halted. By default, the emulated system will be powered off automatically when a halt is detected (that is, the Charon-PAR process will be stopped).

Depending on the Charon-PAR version one of the following two parameters can be used to influence this behavior.

Charon-PAR Versions 3.0.5 to 3.0.12 (system.stop_on_halt)

The system.stop_on_halt parameter has the following syntax:

Syntax:

system.stop_on_halt = false | true

Parameters:

If set to false, Charon-PAR will not stop the emulated system automatically after the guest operating system has been halted. The emulator must be stopped from the Charon-PAR console (at the pa9-64> or pa9-32> prompt).

Default: true. the emulated system will be stopped automatically after the HP-UX guest operating system has been halted.

Charon-PAR Versions 3.0.13 and Higher (system.stop_on_halt_timeout)

The system.stop_on_halt_timeout parameter has the following syntax:

Syntax:

system.stop_on_halt_timeout = <number-of-seconds>

Parameter:

If number-of-seconds is set to 0, Charon-PAR will not stop the emulated system automatically after the HP-UX guest operating system has been halted. The emulator must be stopped from the Charon-PAR console (at the pa9-64> or pa9-32> prompt).

If number-of-seconds is set to a value higher than 0, Charon-PAR will stop the emulated system automatically after the HP-UX guest operating system has been halted using a timeout corresponding to the specified number of seconds.

This parameter has no default value. To restore the default behavior of the system, comment out or remove the parameter from the emulator configuration file.

Parameter system.do_affinity

If enabled, the emulator will calculate a CPU affinity mask based on the host system and the emulator configuration. The affinity mask shows which CPUs will be used for emulated CPUs and which for I/O.

Syntax:

system.do_affinity = false | true

Parameters:

Default: false. The emulator will not follow any preferred host CPU affinity settings.

If set to true, Charon-PAR will calculate a hexadecimal affinity mask according to which emulated CPU and I/O threads will be distributed across the Charon host CPUs. The calculated mask is shown in the emulator log file.

Every bit in the calculated affinity mask corresponds to one host CPU (counting from 0). For example: 00000001 corresponds to to CPU 0, 00000003 corresponds to CPU 0 and 1.

The CPUs that can be used by the emulator can be limited by starting the emulator with an explicit affinity mask defined by the taskset command.
Example: # taskset 2f /opt/charon/bin/charon-par -f myconfigfile.cfg
This would set the affinity mask such that the emulator would only use CPUs 0-3 and 5. If do_affinity is enabled, the automatic calculation will be restricted to the CPUs allowed by the taskset command.