CPU Allocation

The CPU allocation mechanism uses the following constraints for CPU resources:

• Whole-core constraint. This constraint specifies that CPU cores are allocated to a domain rather than to virtual CPUs. As long as the domain does not have the max-cores constraint enabled, the whole-core constraint is dynamic, which means that it can be added or removed by using the ldm set-core or ldm set-vcpu command, respectively. The domain can be inactive, bound, or active. However, there must be enough cores available to satisfy the request to apply the constraint. As a worst-case example, if a domain that shares cores with another domain requests the whole-core constraint, cores from the free list would need to be available to satisfy the request. As a best-case example, all the virtual CPUs in the core are already on core boundaries, so the constraint is applied without changes to CPU resources.

• Maximum number of cores (max-cores) constraint. This constraint specifies the maximum number of cores that can be assigned to a bound or active domain.

  ---

  Note - The max-cores property cannot be altered unless the domain is stopped and unbound, or the control domain is placed in a delayed reconfiguration. So, to increase the maximum number of cores from the value specified at the time the whole-core constraint was enabled, you must first stop and unbind the domain.

  ---

How to Apply the Whole-Core Constraint

It is best to ensure that the control domain has the whole-core constraint enabled prior to setting the max-cores constraint.

1. Apply the whole-core constraint on the primary domain.

   # ldm set-core 1 primary

2. Verify that the control domain has the whole-core constraint enabled.

   # ldm ls -o re primary

   Notice that max-cores is set to unlimited. As is the case with any domain, the control domain cannot be used in conjunction with hard partitioning until the max-cores constraint is enabled.

3. Initiate a delayed reconfiguration on the primary domain.

   # ldm start-reconf primary

4. Enable the max-cores constraint on the primary domain.

   # ldm set-domain max-cores=number-of-CPU-cores primary

   ---

   Note - The cryptographic units that are associated with those cores are unaffected by core additions. So, the system does not automatically add the associated cryptographic units to the domain. However, a cryptographic unit is automatically removed only when the last virtual CPU of the core is being removed. This action prevents a cryptographic unit from being “orphaned.”

   ---

   You can only disable the max-cores constraint on an inactive domain, not on a domain that is bound or active. Before you disable the max-cores constraint on the control domain, you must first initiate a delayed reconfiguration.

5. Verify that the whole-core constraint is enabled.

   # ldm ls -o re primary

6. Reboot the primary domain.

   # reboot

   Upon reboot, you can use the control domain with hard partitioning.

Example 10-1 Applying the Whole-Core Constraint

This example shows how to apply the whole-core constraint on the primary domain. The first command applies the constraint, while the second command verifies that it is enabled:

# ldm set-core 1 primary
# ldm ls -o re primary
NAME
primary

CONSTRAINT
    cpu=whole-core
    max-cores=unlimited
    threading=max-throughput

The following commands constrain max-cores to three cores by initiating a delayed reconfiguration, setting the max-cores property, and verifying that the constraint is enabled:

# ldm start-reconf primary
Initiating a delayed reconfiguration operation on the primary domain.
All configuration changes for other domains are disabled until the primary
domain reboots, at which time the new configuration for the primary domain
will also take effect.

# ldm set-domain max-cores=3 primary

------------------------------------------------------------------------------
Notice: The primary domain is in the process of a delayed reconfiguration.
Any changes made to the primary domain will only take effect after it reboots.
------------------------------------------------------------------------------

# ldm ls -o re primary
NAME
primary

FLAGS
normal,delayed(modify),control,vio-service

CONSTRAINT
    cpu=whole-core
    max-cores=3
    threading=max-throughput

Upon reboot, you can use the control domain with hard partitioning.

The following example removes the max-cores constraint, but leaves the whole-core constraint on the ldg1 domain:

# ldm set-domain max-cores=unlimited ldg1

To remove both the max-cores constraint and the whole-core constraint from the ldg1 domain, assign virtual CPUs instead of cores as follows:

# ldm set-vcpu 8 ldg1

Interactions Between the Whole-Core Constraint and Other Domain Features

This section describes the interactions between the whole-core constraint and the following features:

• CPU Dynamic Reconfiguration

• Dynamic Resource Management

• Domain Migration

• Power Management

CPU Dynamic Reconfiguration

The whole-core constraint is fully compatible with CPU dynamic reconfiguration (DR). When a domain is defined with the whole-core constraint, you can use the ldm add-core, ldm set-core, or ldm remove-core command to change the number of cores on an active domain.

However, if a bound or active domain is not in delayed reconfiguration mode, its number of cores cannot exceed the maximum number of cores. This maximum is set with the maximum core constraint, which is automatically enabled when the whole-core constraint is enabled. Any CPU DR operation that does not satisfy the maximum core constraint fails.

Dynamic Resource Management

The whole-core constraint is not compatible with dynamic resource management (DRM). When a DRM policy is enabled on a domain that uses the whole-core constraint, the policy is automatically disabled. The whole-core constraint remains enabled.

Even though a DRM policy cannot be enabled when the whole-core constraint is in effect, you can still define a DRM policy for the domain. Note that when a policy is automatically disabled, it still remains active. The policy is automatically re-enabled if the domain is restarted without the whole-core constraint.

The following are the expected interactions between the whole-core constraint and DRM:

• If the whole-core constraint is set on a domain, a warning message is issued when you attempt to enable a DRM policy on that domain.

• If a DRM policy is in effect on an inactive domain, you are permitted to enable the whole-core constraint on the domain. When the domain becomes active and the policy is enabled, the system automatically disables the DRM policy for the domain.

• If a DRM policy is enabled on an active or bound domain, you are not permitted to enable the whole-core constraint.

Domain Migration

CPU whole-core configuration is incompatible with domain migration. However, you can still migrate a domain that is configured with CPU whole cores. After such a migration, hard partitioning is not enforced on the target system. Also, the whole-core configuration and the maximum number of CPU cores are not preserved on the target system.

If you migrate a domain that is configured with whole cores, you must reconfigure the target domain to use hard partitioning after the migration completes. Also, you must ensure that your license agreement permits you to use the domain on both the source and target systems.

Power Management

The whole-core constraint is fully compatible with the power management (PM) performance and elastic policies. When the elastic policy is in effect, the PM subsystem can add or remove CPU cores to or from domains that are configured with the whole-core constraint. In that case, the whole-core constraint continues to be honored, and domains that use that constraint remain configured only with whole cores.