| 1 | Arm CPU Features |
| 2 | ================ |
| 3 | |
| 4 | CPU features are optional features that a CPU of supporting type may |
| 5 | choose to implement or not. In QEMU, optional CPU features have |
| 6 | corresponding boolean CPU proprieties that, when enabled, indicate |
| 7 | that the feature is implemented, and, conversely, when disabled, |
| 8 | indicate that it is not implemented. An example of an Arm CPU feature |
| 9 | is the Performance Monitoring Unit (PMU). CPU types such as the |
| 10 | Cortex-A15 and the Cortex-A57, which respectively implement Arm |
| 11 | architecture reference manuals ARMv7-A and ARMv8-A, may both optionally |
| 12 | implement PMUs. For example, if a user wants to use a Cortex-A15 without |
| 13 | a PMU, then the ``-cpu`` parameter should contain ``pmu=off`` on the QEMU |
| 14 | command line, i.e. ``-cpu cortex-a15,pmu=off``. |
| 15 | |
| 16 | As not all CPU types support all optional CPU features, then whether or |
| 17 | not a CPU property exists depends on the CPU type. For example, CPUs |
| 18 | that implement the ARMv8-A architecture reference manual may optionally |
| 19 | support the AArch32 CPU feature, which may be enabled by disabling the |
| 20 | ``aarch64`` CPU property. A CPU type such as the Cortex-A15, which does |
| 21 | not implement ARMv8-A, will not have the ``aarch64`` CPU property. |
| 22 | |
| 23 | QEMU's support may be limited for some CPU features, only partially |
| 24 | supporting the feature or only supporting the feature under certain |
| 25 | configurations. For example, the ``aarch64`` CPU feature, which, when |
| 26 | disabled, enables the optional AArch32 CPU feature, can only be set to |
| 27 | ``off`` on the TCG and KVM accelerators, and it cannot be set to |
| 28 | ``off`` under KVM unless running on a host CPU type that supports |
| 29 | running guests in AArch32. |
| 30 | |
| 31 | CPU features that are inherently specific to KVM are |
| 32 | prefixed with "kvm-" and are described in "KVM VCPU Features". |
| 33 | |
| 34 | CPU Feature Probing |
| 35 | =================== |
| 36 | |
| 37 | Determining which CPU features are available and functional for a given |
| 38 | CPU type is possible with the ``query-cpu-model-expansion`` QMP command. |
| 39 | Below are some examples where ``scripts/qmp/qmp-shell`` (see the top comment |
| 40 | block in the script for usage) is used to issue the QMP commands. |
| 41 | |
| 42 | 1. Determine which CPU features are available for the ``max`` CPU type |
| 43 | (Note, we started QEMU with qemu-system-aarch64, so ``max`` is |
| 44 | implementing the ARMv8-A reference manual in this case):: |
| 45 | |
| 46 | (QEMU) query-cpu-model-expansion type=full model={"name":"max"} |
| 47 | { "return": { |
| 48 | "model": { "name": "max", "props": { |
| 49 | "sve1664": true, "pmu": true, "sve1792": true, "sve1920": true, |
| 50 | "sve128": true, "aarch64": true, "sve1024": true, "sve": true, |
| 51 | "sve640": true, "sve768": true, "sve1408": true, "sve256": true, |
| 52 | "sve1152": true, "sve512": true, "sve384": true, "sve1536": true, |
| 53 | "sve896": true, "sve1280": true, "sve2048": true |
| 54 | }}}} |
| 55 | |
| 56 | We see that the ``max`` CPU type has the ``pmu``, ``aarch64``, ``sve``, and many |
| 57 | ``sve<N>`` CPU features. We also see that all the CPU features are |
| 58 | enabled, as they are all ``true``. (The ``sve<N>`` CPU features are all |
| 59 | optional SVE vector lengths (see "SVE CPU Properties"). While with TCG |
| 60 | all SVE vector lengths can be supported, when KVM is in use it's more |
| 61 | likely that only a few lengths will be supported, if SVE is supported at |
| 62 | all.) |
| 63 | |
| 64 | (2) Let's try to disable the PMU:: |
| 65 | |
| 66 | (QEMU) query-cpu-model-expansion type=full model={"name":"max","props":{"pmu":false}} |
| 67 | { "return": { |
| 68 | "model": { "name": "max", "props": { |
| 69 | "sve1664": true, "pmu": false, "sve1792": true, "sve1920": true, |
| 70 | "sve128": true, "aarch64": true, "sve1024": true, "sve": true, |
| 71 | "sve640": true, "sve768": true, "sve1408": true, "sve256": true, |
| 72 | "sve1152": true, "sve512": true, "sve384": true, "sve1536": true, |
| 73 | "sve896": true, "sve1280": true, "sve2048": true |
| 74 | }}}} |
| 75 | |
| 76 | We see it worked, as ``pmu`` is now ``false``. |
| 77 | |
| 78 | (3) Let's try to disable ``aarch64``, which enables the AArch32 CPU feature:: |
| 79 | |
| 80 | (QEMU) query-cpu-model-expansion type=full model={"name":"max","props":{"aarch64":false}} |
| 81 | {"error": { |
| 82 | "class": "GenericError", "desc": |
| 83 | "'aarch64' feature cannot be disabled unless KVM is enabled and 32-bit EL1 is supported" |
| 84 | }} |
| 85 | |
| 86 | It looks like this feature is limited to a configuration we do not |
| 87 | currently have. |
| 88 | |
| 89 | (4) Let's disable ``sve`` and see what happens to all the optional SVE |
| 90 | vector lengths:: |
| 91 | |
| 92 | (QEMU) query-cpu-model-expansion type=full model={"name":"max","props":{"sve":false}} |
| 93 | { "return": { |
| 94 | "model": { "name": "max", "props": { |
| 95 | "sve1664": false, "pmu": true, "sve1792": false, "sve1920": false, |
| 96 | "sve128": false, "aarch64": true, "sve1024": false, "sve": false, |
| 97 | "sve640": false, "sve768": false, "sve1408": false, "sve256": false, |
| 98 | "sve1152": false, "sve512": false, "sve384": false, "sve1536": false, |
| 99 | "sve896": false, "sve1280": false, "sve2048": false |
| 100 | }}}} |
| 101 | |
| 102 | As expected they are now all ``false``. |
| 103 | |
| 104 | (5) Let's try probing CPU features for the Cortex-A15 CPU type:: |
| 105 | |
| 106 | (QEMU) query-cpu-model-expansion type=full model={"name":"cortex-a15"} |
| 107 | {"return": {"model": {"name": "cortex-a15", "props": {"pmu": true}}}} |
| 108 | |
| 109 | Only the ``pmu`` CPU feature is available. |
| 110 | |
| 111 | A note about CPU feature dependencies |
| 112 | ------------------------------------- |
| 113 | |
| 114 | It's possible for features to have dependencies on other features. I.e. |
| 115 | it may be possible to change one feature at a time without error, but |
| 116 | when attempting to change all features at once an error could occur |
| 117 | depending on the order they are processed. It's also possible changing |
| 118 | all at once doesn't generate an error, because a feature's dependencies |
| 119 | are satisfied with other features, but the same feature cannot be changed |
| 120 | independently without error. For these reasons callers should always |
| 121 | attempt to make their desired changes all at once in order to ensure the |
| 122 | collection is valid. |
| 123 | |
| 124 | A note about CPU models and KVM |
| 125 | ------------------------------- |
| 126 | |
| 127 | Named CPU models generally do not work with KVM. There are a few cases |
| 128 | that do work, e.g. using the named CPU model ``cortex-a57`` with KVM on a |
| 129 | seattle host, but mostly if KVM is enabled the ``host`` CPU type must be |
| 130 | used. This means the guest is provided all the same CPU features as the |
| 131 | host CPU type has. And, for this reason, the ``host`` CPU type should |
| 132 | enable all CPU features that the host has by default. Indeed it's even |
| 133 | a bit strange to allow disabling CPU features that the host has when using |
| 134 | the ``host`` CPU type, but in the absence of CPU models it's the best we can |
| 135 | do if we want to launch guests without all the host's CPU features enabled. |
| 136 | |
| 137 | Enabling KVM also affects the ``query-cpu-model-expansion`` QMP command. The |
| 138 | affect is not only limited to specific features, as pointed out in example |
| 139 | (3) of "CPU Feature Probing", but also to which CPU types may be expanded. |
| 140 | When KVM is enabled, only the ``max``, ``host``, and current CPU type may be |
| 141 | expanded. This restriction is necessary as it's not possible to know all |
| 142 | CPU types that may work with KVM, but it does impose a small risk of users |
| 143 | experiencing unexpected errors. For example on a seattle, as mentioned |
| 144 | above, the ``cortex-a57`` CPU type is also valid when KVM is enabled. |
| 145 | Therefore a user could use the ``host`` CPU type for the current type, but |
| 146 | then attempt to query ``cortex-a57``, however that query will fail with our |
| 147 | restrictions. This shouldn't be an issue though as management layers and |
| 148 | users have been preferring the ``host`` CPU type for use with KVM for quite |
| 149 | some time. Additionally, if the KVM-enabled QEMU instance running on a |
| 150 | seattle host is using the ``cortex-a57`` CPU type, then querying ``cortex-a57`` |
| 151 | will work. |
| 152 | |
| 153 | Using CPU Features |
| 154 | ================== |
| 155 | |
| 156 | After determining which CPU features are available and supported for a |
| 157 | given CPU type, then they may be selectively enabled or disabled on the |
| 158 | QEMU command line with that CPU type:: |
| 159 | |
| 160 | $ qemu-system-aarch64 -M virt -cpu max,pmu=off,sve=on,sve128=on,sve256=on |
| 161 | |
| 162 | The example above disables the PMU and enables the first two SVE vector |
| 163 | lengths for the ``max`` CPU type. Note, the ``sve=on`` isn't actually |
| 164 | necessary, because, as we observed above with our probe of the ``max`` CPU |
| 165 | type, ``sve`` is already on by default. Also, based on our probe of |
| 166 | defaults, it would seem we need to disable many SVE vector lengths, rather |
| 167 | than only enabling the two we want. This isn't the case, because, as |
| 168 | disabling many SVE vector lengths would be quite verbose, the ``sve<N>`` CPU |
| 169 | properties have special semantics (see "SVE CPU Property Parsing |
| 170 | Semantics"). |
| 171 | |
| 172 | KVM VCPU Features |
| 173 | ================= |
| 174 | |
| 175 | KVM VCPU features are CPU features that are specific to KVM, such as |
| 176 | paravirt features or features that enable CPU virtualization extensions. |
| 177 | The features' CPU properties are only available when KVM is enabled and |
| 178 | are named with the prefix "kvm-". KVM VCPU features may be probed, |
| 179 | enabled, and disabled in the same way as other CPU features. Below is |
| 180 | the list of KVM VCPU features and their descriptions. |
| 181 | |
| 182 | ``kvm-no-adjvtime`` |
| 183 | By default kvm-no-adjvtime is disabled. This means that by default |
| 184 | the virtual time adjustment is enabled (vtime is not *not* adjusted). |
| 185 | |
| 186 | When virtual time adjustment is enabled each time the VM transitions |
| 187 | back to running state the VCPU's virtual counter is updated to |
| 188 | ensure stopped time is not counted. This avoids time jumps |
| 189 | surprising guest OSes and applications, as long as they use the |
| 190 | virtual counter for timekeeping. However it has the side effect of |
| 191 | the virtual and physical counters diverging. All timekeeping based |
| 192 | on the virtual counter will appear to lag behind any timekeeping |
| 193 | that does not subtract VM stopped time. The guest may resynchronize |
| 194 | its virtual counter with other time sources as needed. |
| 195 | |
| 196 | Enable kvm-no-adjvtime to disable virtual time adjustment, also |
| 197 | restoring the legacy (pre-5.0) behavior. |
| 198 | |
| 199 | ``kvm-steal-time`` |
| 200 | Since v5.2, kvm-steal-time is enabled by default when KVM is |
| 201 | enabled, the feature is supported, and the guest is 64-bit. |
| 202 | |
| 203 | When kvm-steal-time is enabled a 64-bit guest can account for time |
| 204 | its CPUs were not running due to the host not scheduling the |
| 205 | corresponding VCPU threads. The accounting statistics may influence |
| 206 | the guest scheduler behavior and/or be exposed to the guest |
| 207 | userspace. |
| 208 | |
| 209 | ``kvm-psci-version`` |
| 210 | Set the Power State Coordination Interface (PSCI) firmware ABI version |
| 211 | that KVM provides to the guest. By default KVM will use the newest |
| 212 | version that it knows about (which is PSCI v1.3 in Linux v6.13). |
| 213 | |
| 214 | You only need to set this if you want to be able to migrate this |
| 215 | VM to a host machine running an older kernel that does not |
| 216 | recognize the PSCI version that this host's kernel defaults to. |
| 217 | |
| 218 | Current valid values are: 0.1, 0.2, 1.0, 1.1, 1.2, and 1.3. |
| 219 | |
| 220 | TCG VCPU Features |
| 221 | ================= |
| 222 | |
| 223 | TCG VCPU features are CPU features that are specific to TCG. |
| 224 | Below is the list of TCG VCPU features and their descriptions. |
| 225 | |
| 226 | ``pauth`` |
| 227 | Enable or disable ``FEAT_Pauth`` entirely. |
| 228 | |
| 229 | ``pauth-impdef`` |
| 230 | When ``pauth`` is enabled, select the QEMU implementation defined algorithm. |
| 231 | |
| 232 | ``pauth-qarma3`` |
| 233 | When ``pauth`` is enabled, select the architected QARMA3 algorithm. |
| 234 | |
| 235 | ``pauth-qarma5`` |
| 236 | When ``pauth`` is enabled, select the architected QARMA5 algorithm. |
| 237 | |
| 238 | Without ``pauth-impdef``, ``pauth-qarma3`` or ``pauth-qarma5`` enabled, |
| 239 | the QEMU impdef algorithm is used. The architected QARMA5 |
| 240 | and QARMA3 algorithms have good cryptographic properties, but can |
| 241 | be quite slow to emulate. The impdef algorithm used by QEMU is |
| 242 | non-cryptographic but significantly faster. |
| 243 | |
| 244 | SVE CPU Properties |
| 245 | ================== |
| 246 | |
| 247 | There are two types of SVE CPU properties: ``sve`` and ``sve<N>``. The first |
| 248 | is used to enable or disable the entire SVE feature, just as the ``pmu`` |
| 249 | CPU property completely enables or disables the PMU. The second type |
| 250 | is used to enable or disable specific vector lengths, where ``N`` is the |
| 251 | number of bits of the length. The ``sve<N>`` CPU properties have special |
| 252 | dependencies and constraints, see "SVE CPU Property Dependencies and |
| 253 | Constraints" below. Additionally, as we want all supported vector lengths |
| 254 | to be enabled by default, then, in order to avoid overly verbose command |
| 255 | lines (command lines full of ``sve<N>=off``, for all ``N`` not wanted), we |
| 256 | provide the parsing semantics listed in "SVE CPU Property Parsing |
| 257 | Semantics". |
| 258 | |
| 259 | SVE CPU Property Dependencies and Constraints |
| 260 | --------------------------------------------- |
| 261 | |
| 262 | 1) At least one vector length must be enabled when ``sve`` is enabled. |
| 263 | |
| 264 | 2) If a vector length ``N`` is enabled, then, when KVM is enabled, all |
| 265 | smaller, host supported vector lengths must also be enabled. If |
| 266 | KVM is not enabled, then only all the smaller, power-of-two vector |
| 267 | lengths must be enabled. E.g. with KVM if the host supports all |
| 268 | vector lengths up to 512-bits (128, 256, 384, 512), then if ``sve512`` |
| 269 | is enabled, the 128-bit vector length, 256-bit vector length, and |
| 270 | 384-bit vector length must also be enabled. Without KVM, the 384-bit |
| 271 | vector length would not be required. |
| 272 | |
| 273 | 3) If KVM is enabled then only vector lengths that the host CPU type |
| 274 | support may be enabled. If SVE is not supported by the host, then |
| 275 | no ``sve*`` properties may be enabled. |
| 276 | |
| 277 | SVE CPU Property Parsing Semantics |
| 278 | ---------------------------------- |
| 279 | |
| 280 | 1) If SVE is disabled (``sve=off``), then which SVE vector lengths |
| 281 | are enabled or disabled is irrelevant to the guest, as the entire |
| 282 | SVE feature is disabled and that disables all vector lengths for |
| 283 | the guest. However QEMU will still track any ``sve<N>`` CPU |
| 284 | properties provided by the user. If later an ``sve=on`` is provided, |
| 285 | then the guest will get only the enabled lengths. If no ``sve=on`` |
| 286 | is provided and there are explicitly enabled vector lengths, then |
| 287 | an error is generated. |
| 288 | |
| 289 | 2) If SVE is enabled (``sve=on``), but no ``sve<N>`` CPU properties are |
| 290 | provided, then all supported vector lengths are enabled, which when |
| 291 | KVM is not in use means including the non-power-of-two lengths, and, |
| 292 | when KVM is in use, it means all vector lengths supported by the host |
| 293 | processor. |
| 294 | |
| 295 | 3) If SVE is enabled, then an error is generated when attempting to |
| 296 | disable the last enabled vector length (see constraint (1) of "SVE |
| 297 | CPU Property Dependencies and Constraints"). |
| 298 | |
| 299 | 4) If one or more vector lengths have been explicitly enabled and at |
| 300 | least one of the dependency lengths of the maximum enabled length |
| 301 | has been explicitly disabled, then an error is generated (see |
| 302 | constraint (2) of "SVE CPU Property Dependencies and Constraints"). |
| 303 | |
| 304 | 5) When KVM is enabled, if the host does not support SVE, then an error |
| 305 | is generated when attempting to enable any ``sve*`` properties (see |
| 306 | constraint (3) of "SVE CPU Property Dependencies and Constraints"). |
| 307 | |
| 308 | 6) When KVM is enabled, if the host does support SVE, then an error is |
| 309 | generated when attempting to enable any vector lengths not supported |
| 310 | by the host (see constraint (3) of "SVE CPU Property Dependencies and |
| 311 | Constraints"). |
| 312 | |
| 313 | 7) If one or more ``sve<N>`` CPU properties are set ``off``, but no ``sve<N>``, |
| 314 | CPU properties are set ``on``, then the specified vector lengths are |
| 315 | disabled but the default for any unspecified lengths remains enabled. |
| 316 | When KVM is not enabled, disabling a power-of-two vector length also |
| 317 | disables all vector lengths larger than the power-of-two length. |
| 318 | When KVM is enabled, then disabling any supported vector length also |
| 319 | disables all larger vector lengths (see constraint (2) of "SVE CPU |
| 320 | Property Dependencies and Constraints"). |
| 321 | |
| 322 | 8) If one or more ``sve<N>`` CPU properties are set to ``on``, then they |
| 323 | are enabled and all unspecified lengths default to disabled, except |
| 324 | for the required lengths per constraint (2) of "SVE CPU Property |
| 325 | Dependencies and Constraints", which will even be auto-enabled if |
| 326 | they were not explicitly enabled. |
| 327 | |
| 328 | 9) If SVE was disabled (``sve=off``), allowing all vector lengths to be |
| 329 | explicitly disabled (i.e. avoiding the error specified in (3) of |
| 330 | "SVE CPU Property Parsing Semantics"), then if later an ``sve=on`` is |
| 331 | provided an error will be generated. To avoid this error, one must |
| 332 | enable at least one vector length prior to enabling SVE. |
| 333 | |
| 334 | 10) Enabling SVE (with ``sve=on`` or by default) enables all the SVE |
| 335 | sub-features that the CPU supports (for example, it may also |
| 336 | enable SVE2). There are not generally any lower-level controls |
| 337 | for disabling specific SVE sub-features. |
| 338 | |
| 339 | 11) Disabling SVE does not automatically disable SME. If you want to |
| 340 | disable both you must use ``sve=off,sme=off``. In particular, |
| 341 | for the ``max`` CPU, ``sve=off`` alone will give you a CPU with |
| 342 | SME only (and which therefore still has the SVE vector registers). |
| 343 | Most users will want to disable both at once. |
| 344 | |
| 345 | SVE CPU Property Examples |
| 346 | ------------------------- |
| 347 | |
| 348 | 1) Disable SVE and SME:: |
| 349 | |
| 350 | $ qemu-system-aarch64 -M virt -cpu max,sve=off,sme=off |
| 351 | |
| 352 | 2) Implicitly enable all vector lengths for the ``max`` CPU type:: |
| 353 | |
| 354 | $ qemu-system-aarch64 -M virt -cpu max |
| 355 | |
| 356 | 3) When KVM is enabled, implicitly enable all host CPU supported vector |
| 357 | lengths with the ``host`` CPU type:: |
| 358 | |
| 359 | $ qemu-system-aarch64 -M virt,accel=kvm -cpu host |
| 360 | |
| 361 | 4) Only enable the 128-bit vector length:: |
| 362 | |
| 363 | $ qemu-system-aarch64 -M virt -cpu max,sve128=on |
| 364 | |
| 365 | 5) Disable the 512-bit vector length and all larger vector lengths, |
| 366 | since 512 is a power-of-two. This results in all the smaller, |
| 367 | uninitialized lengths (128, 256, and 384) defaulting to enabled:: |
| 368 | |
| 369 | $ qemu-system-aarch64 -M virt -cpu max,sve512=off |
| 370 | |
| 371 | 6) Enable the 128-bit, 256-bit, and 512-bit vector lengths:: |
| 372 | |
| 373 | $ qemu-system-aarch64 -M virt -cpu max,sve128=on,sve256=on,sve512=on |
| 374 | |
| 375 | 7) The same as (6), but since the 128-bit and 256-bit vector |
| 376 | lengths are required for the 512-bit vector length to be enabled, |
| 377 | then allow them to be auto-enabled:: |
| 378 | |
| 379 | $ qemu-system-aarch64 -M virt -cpu max,sve512=on |
| 380 | |
| 381 | 8) Do the same as (7), but by first disabling SVE and then re-enabling it:: |
| 382 | |
| 383 | $ qemu-system-aarch64 -M virt -cpu max,sve=off,sve512=on,sve=on |
| 384 | |
| 385 | 9) Force errors regarding the last vector length:: |
| 386 | |
| 387 | $ qemu-system-aarch64 -M virt -cpu max,sve128=off |
| 388 | $ qemu-system-aarch64 -M virt -cpu max,sve=off,sve128=off,sve=on |
| 389 | |
| 390 | SVE CPU Property Recommendations |
| 391 | -------------------------------- |
| 392 | |
| 393 | The examples in "SVE CPU Property Examples" exhibit many ways to select |
| 394 | vector lengths which developers may find useful in order to avoid overly |
| 395 | verbose command lines. However, the recommended way to select vector |
| 396 | lengths is to explicitly enable each desired length. Therefore only |
| 397 | example's (1), (4), and (6) exhibit recommended uses of the properties. |
| 398 | |
| 399 | SME CPU Property Examples |
| 400 | ------------------------- |
| 401 | |
| 402 | 1) Disable SME:: |
| 403 | |
| 404 | $ qemu-system-aarch64 -M virt -cpu max,sme=off |
| 405 | |
| 406 | 2) Implicitly enable all vector lengths for the ``max`` CPU type:: |
| 407 | |
| 408 | $ qemu-system-aarch64 -M virt -cpu max |
| 409 | |
| 410 | 3) Only enable the 256-bit vector length:: |
| 411 | |
| 412 | $ qemu-system-aarch64 -M virt -cpu max,sme256=on |
| 413 | |
| 414 | 3) Enable the 256-bit and 1024-bit vector lengths:: |
| 415 | |
| 416 | $ qemu-system-aarch64 -M virt -cpu max,sme256=on,sme1024=on |
| 417 | |
| 418 | 4) Disable the 512-bit vector length. This results in all the other |
| 419 | lengths supported by ``max`` defaulting to enabled |
| 420 | (128, 256, 1024 and 2048):: |
| 421 | |
| 422 | $ qemu-system-aarch64 -M virt -cpu max,sve512=off |
| 423 | |
| 424 | SVE User-mode Default Vector Length Property |
| 425 | -------------------------------------------- |
| 426 | |
| 427 | For qemu-aarch64, the cpu property ``sve-default-vector-length=N`` is |
| 428 | defined to mirror the Linux kernel parameter file |
| 429 | ``/proc/sys/abi/sve_default_vector_length``. The default length, ``N``, |
| 430 | is in units of bytes and must be between 16 and 8192. |
| 431 | If not specified, the default vector length is 64. |
| 432 | |
| 433 | If the default length is larger than the maximum vector length enabled, |
| 434 | the actual vector length will be reduced. Note that the maximum vector |
| 435 | length supported by QEMU is 256. |
| 436 | |
| 437 | If this property is set to ``-1`` then the default vector length |
| 438 | is set to the maximum possible length. |
| 439 | |
| 440 | SME CPU Properties |
| 441 | ================== |
| 442 | |
| 443 | The SME CPU properties are much like the SVE properties: ``sme`` is |
| 444 | used to enable or disable the entire SME feature, and ``sme<N>`` is |
| 445 | used to enable or disable specific vector lengths. Finally, |
| 446 | ``sme_fa64`` is used to enable or disable ``FEAT_SME_FA64``, which |
| 447 | allows execution of the "full a64" instruction set while Streaming |
| 448 | SVE mode is enabled. |
| 449 | |
| 450 | SME is not supported by KVM at this time. |
| 451 | |
| 452 | At least one vector length must be enabled when ``sme`` is enabled, |
| 453 | and all vector lengths must be powers of 2. The maximum vector |
| 454 | length supported by qemu is 2048 bits. Otherwise, there are no |
| 455 | additional constraints on the set of vector lengths supported by SME. |
| 456 | |
| 457 | As with SVE, ``sme=on`` enables all the SME sub-features the CPU |
| 458 | supports (for example, it may also enable SME2), and there are |
| 459 | no lower-level controls for fine-grained disabling of specific |
| 460 | SME sub-features. |
| 461 | |
| 462 | SME User-mode Default Vector Length Property |
| 463 | -------------------------------------------- |
| 464 | |
| 465 | For qemu-aarch64, the cpu property ``sme-default-vector-length=N`` is |
| 466 | defined to mirror the Linux kernel parameter file |
| 467 | ``/proc/sys/abi/sme_default_vector_length``. The default length, ``N``, |
| 468 | is in units of bytes and must be between 16 and 8192. |
| 469 | If not specified, the default vector length is 32. |
| 470 | |
| 471 | As with ``sve-default-vector-length``, if the default length is larger |
| 472 | than the maximum vector length enabled, the actual vector length will |
| 473 | be reduced. If this property is set to ``-1`` then the default vector |
| 474 | length is set to the maximum possible length. |
| 475 | |
| 476 | RME CPU Properties |
| 477 | ================== |
| 478 | |
| 479 | The status of RME support with QEMU is experimental. At this time we |
| 480 | only support RME within the CPU proper, not within the SMMU or GIC. |
| 481 | The feature is enabled by the CPU property ``x-rme``, with the ``x-`` |
| 482 | prefix present as a reminder of the experimental status, and defaults off. |
| 483 | |
| 484 | The method for enabling RME will change in some future QEMU release |
| 485 | without notice or backward compatibility. |
| 486 | |
| 487 | RME Level 0 GPT Size Property |
| 488 | ----------------------------- |
| 489 | |
| 490 | To aid firmware developers in testing different possible CPU |
| 491 | configurations, ``x-l0gptsz=S`` may be used to specify the value |
| 492 | to encode into ``GPCCR_EL3.L0GPTSZ``, a read-only field that |
| 493 | specifies the size of the Level 0 Granule Protection Table. |
| 494 | Legal values for ``S`` are 30, 34, 36, and 39; the default is 30. |
| 495 | |
| 496 | As with ``x-rme``, the ``x-l0gptsz`` property may be renamed or |
| 497 | removed in some future QEMU release. |