set

Synopsis:

set var val

Options:

The set option supports the following variable types:

• address – use any of the forms permitted for memory sizes when you specify val (e.g., 4K, 0d16384 (see About notation in the Configuration chapter))
• boolean – any of the following values are equivalent; the first term turns on the feature, the second turns it off: 1/0, yes/no, on/off, true/false
• number – any positive integer that can be expressed with 64 bits; decimal notation (no prefix) and hexadecimal notation (prefixed with 0x) are permitted
• string – a text string, used as is

Description:

Each set var val argument pair defines a variable setting that applies to an implicit context. This is different than the VM configuration file notion of a context, which is a group of related configuration options (for details, see Contexts in the VM configuration syntax topic). The implicit context to which each variable applies is noted in its description. Supported implicit contexts include:

• global – applies to the VM (qvm process instance) currently being configured
• guest – applies to the guest currently being configured
• CPU – applies to the vCPU currently being configured
• vdev – applies to the vdev currently being configured

You can display the currently permitted variables and their contexts. For example, from a shell prompt in the host, type:

# qvm set ?

You should see the variable names along with their types and contexts in a listing like the following:

allowed set variables
    grow-heap                      (address, global)
    legacy-free                    (boolean, guest)
    message-block-timeout          (number, global)
    posted-interrupts              (boolean, guest)
    virtual-interrupts             (boolean, guest)

A question mark (?) is a shell wildcard character, so you may need to escape it. If a vdev defines its own variables, ? will list these only after a vdev option has loaded the vdev where these variables are specified.

About the set host-* arguments

The set host-* arguments separate the configuration of the host system from the configuration of the VMs. You can have a single configuration file that provides a host-specific configuration that can be re-used for multiple VMs.

For example, for a fictious foo SoC, you can create a foo.qvmconf file that includes:

set host-ppi-hcnt 16
set host-ppi-vcnt 19
set host-ppi-gic-hwassist 24
set host-paddr-gich 0x0ac01000

which you re-use for all your VMs, in addition to the VM-specific configuration files. For example:

qvm @guest1.qvmconf @foo.qvmconf 
qvm @guest2.qvmconf @foo.qvmconf

Below is an example of how the set option's host-paddr-gic* arguments are used for a Renesas R-Car H3 board:

set host-paddr-gicv 0xf1060000
set host-paddr-gich 0xf1040000,0xf1050000/0/0x200

where host-paddr-gicv 0xf1060000 specifies the host-physical address of the GIC virtual CPU registers, and the host-paddr-gich line specifies the location of the hypervisor control (GICH) registers:

• host-paddr-gich 0xf1040000,0xf1050000/0/0x200 – the host-physical address of the GICH registers that the hardware's virtualization assistance allocates to the current physical CPU
• host-paddr-gich 0xf1040000,0xf1050000/0/0x200 – the host-physical address of physical CPU 0's GICH registers
• host-paddr-gich 0xf1040000,0xf1050000/0/0x200 – the CPU number whose GICH registers are at 0xf1050000, in this case CPU 0
• host-paddr-gich 0xf1040000,0xf1050000/0/0x200 – the spacing between the physical CPU registers. With CPU 0 at 0xf1050000 and a spacing of 0x200 as in this example, the host-physical address to access the registers for physical CPU 1 is 0xf1050200, the address to access the registers for physical CPU 2 is 0xf1050400, and so on.