...

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 historic HP3000 ( Charon-PAR/PA3 ) or HP9000 ( Charon-PAR/PA9 ) hardware model or model family. The files also contain important descriptions for all parameters listed.

...

Comments in the file are preceded by the # character.If a parameter

value is a 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.

...

Parameter license_key_id 

Optional parameter. 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"

...

Optional parameter. 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"

...

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

Syntax:

model "model-name"

...

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

The options available for configuration are described below.

Serial port

...

options

...

type

...

The

...

• socket: the port is set to telnet raw mode.
• telnet: the port supports the telnet protocol.
• device: indicates that the emulated serial line is connected to a physical terminal on the host.

...

Each port is mapped to a TCP socket on the emulator host or to a physical line. This parameter defines the TCP port used or the name of the physical device. A TCP port number must be unique on the host system.

A TCP port number is specified as "<where-to-listen>:<portnumber>". It requires a port type of socket or telnet.

Possible values for where-to-listen:

• Empty:
  • If the port number is specified without a colon (:), the console will only be accessible on the localhost address. Equivalent lo:<portnumber>.
  • If the port number is specified with a colon, the console process will listen on all host interfaces.
• Interface name: the console process will only listen on the specified host interface.
• IP address: the console process will only listen on host IP address.

Default values:

• ":30000" for line 1
• ":30002" for line 2

A physical device is specified as "<device-file>". It requires a port type of device.

Example:

• "/dev/ttyS0"
• "/dev/ttyUSB0"

type option specifies the serial line connection type.

Possible values:

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"

...

serial.uart0.device.command="putty"

To start the xhpterm emulator (HP3000), 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.

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.

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: 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 or container file.

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: 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:

...

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.

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.

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: 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: 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 -or-file: the path to the Linux device or container file.

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: 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.
• sizepath-into-bytesdevice: 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, or
• to a TAP interface on the host.

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.
• An automatically created TAP interface is deleted automatically upon emulator stop.

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.

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 named system.lan0.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:

...

Possible values:

• RAW: the emulated Ethernet card is mapped to a physical interface on the Charon host that is dedicated to the Charon guest system. This setting is the default value.
• TAP: the emulated Ethernet card is mapped to a TAP device on the Charon host. If the parameter iface is not set or the specified interface does not exist, it is created by the emulator.
• DUMMY: presents a network interface without any actual network connectivity to the guest system. All other Ethernet parameters are ignored if this parameter is set.
  It will be set automatically, if
  • iface="dummy",
  • or iface="" and mapping_mode="RAW".

...

Specifies the name of the host interface mapped to the emulated interface.

For mapping_mode="RAW": this parameter must be set to an interface dedicated to the emulator.

For mapping_mode="TAP": the parameter can be

• empty: the emulator will choose a name for the TAP interface and create it automatically at startup (and delete it when stopped).
• name of non-existing TAP interface: the emulator will create the interface automatically at startup (and delete it when stopped).
• name of an existing TAP interface: the emulator will use this interface.

For any mapping_mode: the value dummy will cause the emulator to present a dummy network interface to the guest system.

Upon emulator start, Charon-PAR will set a variable IFACE to contain the interface name. This variable can then be used in the initialization command to refer to the interface name.

...

Can be set to override the default (same as host interface) MAC address of the interface.
By default, when using mapping_mode RAW, the interface is put into promiscuous mode, and the original MAC address of the interface is not overwritten.
If the legacy_mode is configured for the interface, it is not set into promiscuous mode, and the MAC address of the corresponding host NIC is changed to the configured address. The original MAC address is restored upon emulator exit.

Please note: the above behavior is new starting with version 3.0.1 build 21.500. In older versions, when the MAC address was changed, it was not reset automatically when the emulator was stopped.

...

initialize_command

...

Command(s) to initialize the host interface for use with the Charon emulator.

• For physical interfaces (RAW): all offload parameters active on the interface should be turned off, as shown by the example in the configuration file template.
• For TAP interfaces: the TAP interface should be activated, if needed, and added to the appropriate bridge interface (example: "ip link set $IFACE up; ip link set $IFACE master br0"); the exact configuration depends on the customer requirements.

The variable IFACE is set by the emulator and defined automatically for the execution of the initialization command.

...

Defines the speed and duplex settings of the interface that are reported to the guest system.

Possible values: auto, 10BaseT-HD, 10BaseT-FD, 100BaseT-HD, 100BaseT-FD
Default: 100BaseT-FD

...

New starting with version 3.0.1 build 21.500. Only applicable to mapping_mode RAW. PA64 uses a physical network adapter in promiscuous mode by default. This parameter allows to change the mode to non-promiscuous.

Possible values:

• true - non-promiscuous mode; if a custom MAC address was set, it will be set on the physical NIC during emulator operation and reset to the burned-in MAC address when the emulator stops.
• false - promiscuous mode; if a custom MAC address was set, it will not be be set on the physical NIC (not required for the guest communication due to promiscuous mode)

Default: false

...

Can be used to enable a packet dump to the log file.
Possible values: true or false
Default: false

...

Can be used to set the size of the RX FIFO buffer (in KB). Do not change unless advised to do so by Stromasys support.
Possible values: 0, or 16 to 1024
Default: 0 = disabled

Logging configuration

This section defines how Charon-PAR handles logging.

Log File Parameters

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

...

• 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, or
• to a TAP interface on the host.

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.

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.

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 named system.lan0.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

...

SuperIO Configuration

General Information

The SuperIO module is included in the Astro chipset and emulates a historic HP9000 PCI board with PC style peripherals:

• 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

...

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:

...

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

Insert excerpt
Configuring SuperIO Devices Configuring SuperIO Devices nopanel true

Div
class pagebreak

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.

Parameter system.stop_on_halt

Available starting from version 3.0.5. This parameter is 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). The stop_on_halt parameter allows the user to influence this behavior.

Syntax:

system.stop_on_halt = false | true

Parameters:

If set to false, Charon-PAR will not check the FMA support of the host CPUstop 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: the check is enabled true. the emulated system will be stopped automatically after the guest operating system has been halted.