Peter Maydell | 34f18ab | 2020-03-09 21:58:17 +0000 | [diff] [blame] | 1 | Arm CPU Features |
Andrew Jones | e19afd5 | 2019-10-31 15:27:26 +0100 | [diff] [blame] | 2 | ================ |
Andrew Jones | e19afd5 | 2019-10-31 15:27:26 +0100 | [diff] [blame] | 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, |
Peter Maydell | 6fe6d6c | 2020-03-09 21:58:18 +0000 | [diff] [blame] | 8 | indicate that it is not implemented. An example of an Arm CPU feature |
Andrew Jones | e19afd5 | 2019-10-31 15:27:26 +0100 | [diff] [blame] | 9 | is the Performance Monitoring Unit (PMU). CPU types such as the |
Peter Maydell | 6fe6d6c | 2020-03-09 21:58:18 +0000 | [diff] [blame] | 10 | Cortex-A15 and the Cortex-A57, which respectively implement Arm |
Andrew Jones | e19afd5 | 2019-10-31 15:27:26 +0100 | [diff] [blame] | 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, is only supported |
| 27 | when using the KVM accelerator and when running on a host CPU type that |
Andrew Jones | dea101a | 2020-01-30 16:02:06 +0000 | [diff] [blame] | 28 | supports the feature. While `aarch64` currently only works with KVM, |
| 29 | it could work with TCG. CPU features that are specific to KVM are |
| 30 | prefixed with "kvm-" and are described in "KVM VCPU Features". |
Andrew Jones | e19afd5 | 2019-10-31 15:27:26 +0100 | [diff] [blame] | 31 | |
| 32 | CPU Feature Probing |
| 33 | =================== |
| 34 | |
| 35 | Determining which CPU features are available and functional for a given |
| 36 | CPU type is possible with the `query-cpu-model-expansion` QMP command. |
| 37 | Below are some examples where `scripts/qmp/qmp-shell` (see the top comment |
| 38 | block in the script for usage) is used to issue the QMP commands. |
| 39 | |
Stefan Hajnoczi | f21673c | 2019-11-11 09:44:11 +0000 | [diff] [blame] | 40 | 1. Determine which CPU features are available for the `max` CPU type |
| 41 | (Note, we started QEMU with qemu-system-aarch64, so `max` is |
| 42 | implementing the ARMv8-A reference manual in this case):: |
Andrew Jones | e19afd5 | 2019-10-31 15:27:26 +0100 | [diff] [blame] | 43 | |
| 44 | (QEMU) query-cpu-model-expansion type=full model={"name":"max"} |
| 45 | { "return": { |
| 46 | "model": { "name": "max", "props": { |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 47 | "sve1664": true, "pmu": true, "sve1792": true, "sve1920": true, |
| 48 | "sve128": true, "aarch64": true, "sve1024": true, "sve": true, |
| 49 | "sve640": true, "sve768": true, "sve1408": true, "sve256": true, |
| 50 | "sve1152": true, "sve512": true, "sve384": true, "sve1536": true, |
| 51 | "sve896": true, "sve1280": true, "sve2048": true |
Andrew Jones | e19afd5 | 2019-10-31 15:27:26 +0100 | [diff] [blame] | 52 | }}}} |
| 53 | |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 54 | We see that the `max` CPU type has the `pmu`, `aarch64`, `sve`, and many |
| 55 | `sve<N>` CPU features. We also see that all the CPU features are |
| 56 | enabled, as they are all `true`. (The `sve<N>` CPU features are all |
| 57 | optional SVE vector lengths (see "SVE CPU Properties"). While with TCG |
| 58 | all SVE vector lengths can be supported, when KVM is in use it's more |
| 59 | likely that only a few lengths will be supported, if SVE is supported at |
| 60 | all.) |
Andrew Jones | e19afd5 | 2019-10-31 15:27:26 +0100 | [diff] [blame] | 61 | |
| 62 | (2) Let's try to disable the PMU:: |
| 63 | |
| 64 | (QEMU) query-cpu-model-expansion type=full model={"name":"max","props":{"pmu":false}} |
| 65 | { "return": { |
| 66 | "model": { "name": "max", "props": { |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 67 | "sve1664": true, "pmu": false, "sve1792": true, "sve1920": true, |
| 68 | "sve128": true, "aarch64": true, "sve1024": true, "sve": true, |
| 69 | "sve640": true, "sve768": true, "sve1408": true, "sve256": true, |
| 70 | "sve1152": true, "sve512": true, "sve384": true, "sve1536": true, |
| 71 | "sve896": true, "sve1280": true, "sve2048": true |
Andrew Jones | e19afd5 | 2019-10-31 15:27:26 +0100 | [diff] [blame] | 72 | }}}} |
| 73 | |
| 74 | We see it worked, as `pmu` is now `false`. |
| 75 | |
| 76 | (3) Let's try to disable `aarch64`, which enables the AArch32 CPU feature:: |
| 77 | |
| 78 | (QEMU) query-cpu-model-expansion type=full model={"name":"max","props":{"aarch64":false}} |
| 79 | {"error": { |
| 80 | "class": "GenericError", "desc": |
| 81 | "'aarch64' feature cannot be disabled unless KVM is enabled and 32-bit EL1 is supported" |
| 82 | }} |
| 83 | |
| 84 | It looks like this feature is limited to a configuration we do not |
| 85 | currently have. |
| 86 | |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 87 | (4) Let's disable `sve` and see what happens to all the optional SVE |
| 88 | vector lengths:: |
| 89 | |
| 90 | (QEMU) query-cpu-model-expansion type=full model={"name":"max","props":{"sve":false}} |
| 91 | { "return": { |
| 92 | "model": { "name": "max", "props": { |
| 93 | "sve1664": false, "pmu": true, "sve1792": false, "sve1920": false, |
| 94 | "sve128": false, "aarch64": true, "sve1024": false, "sve": false, |
| 95 | "sve640": false, "sve768": false, "sve1408": false, "sve256": false, |
| 96 | "sve1152": false, "sve512": false, "sve384": false, "sve1536": false, |
| 97 | "sve896": false, "sve1280": false, "sve2048": false |
| 98 | }}}} |
| 99 | |
| 100 | As expected they are now all `false`. |
| 101 | |
| 102 | (5) Let's try probing CPU features for the Cortex-A15 CPU type:: |
Andrew Jones | e19afd5 | 2019-10-31 15:27:26 +0100 | [diff] [blame] | 103 | |
| 104 | (QEMU) query-cpu-model-expansion type=full model={"name":"cortex-a15"} |
| 105 | {"return": {"model": {"name": "cortex-a15", "props": {"pmu": true}}}} |
| 106 | |
| 107 | Only the `pmu` CPU feature is available. |
| 108 | |
| 109 | A note about CPU feature dependencies |
| 110 | ------------------------------------- |
| 111 | |
| 112 | It's possible for features to have dependencies on other features. I.e. |
| 113 | it may be possible to change one feature at a time without error, but |
| 114 | when attempting to change all features at once an error could occur |
| 115 | depending on the order they are processed. It's also possible changing |
| 116 | all at once doesn't generate an error, because a feature's dependencies |
| 117 | are satisfied with other features, but the same feature cannot be changed |
| 118 | independently without error. For these reasons callers should always |
| 119 | attempt to make their desired changes all at once in order to ensure the |
| 120 | collection is valid. |
| 121 | |
| 122 | A note about CPU models and KVM |
| 123 | ------------------------------- |
| 124 | |
| 125 | Named CPU models generally do not work with KVM. There are a few cases |
| 126 | that do work, e.g. using the named CPU model `cortex-a57` with KVM on a |
| 127 | seattle host, but mostly if KVM is enabled the `host` CPU type must be |
| 128 | used. This means the guest is provided all the same CPU features as the |
| 129 | host CPU type has. And, for this reason, the `host` CPU type should |
| 130 | enable all CPU features that the host has by default. Indeed it's even |
| 131 | a bit strange to allow disabling CPU features that the host has when using |
| 132 | the `host` CPU type, but in the absence of CPU models it's the best we can |
| 133 | do if we want to launch guests without all the host's CPU features enabled. |
| 134 | |
| 135 | Enabling KVM also affects the `query-cpu-model-expansion` QMP command. The |
| 136 | affect is not only limited to specific features, as pointed out in example |
| 137 | (3) of "CPU Feature Probing", but also to which CPU types may be expanded. |
| 138 | When KVM is enabled, only the `max`, `host`, and current CPU type may be |
| 139 | expanded. This restriction is necessary as it's not possible to know all |
| 140 | CPU types that may work with KVM, but it does impose a small risk of users |
| 141 | experiencing unexpected errors. For example on a seattle, as mentioned |
| 142 | above, the `cortex-a57` CPU type is also valid when KVM is enabled. |
| 143 | Therefore a user could use the `host` CPU type for the current type, but |
| 144 | then attempt to query `cortex-a57`, however that query will fail with our |
| 145 | restrictions. This shouldn't be an issue though as management layers and |
| 146 | users have been preferring the `host` CPU type for use with KVM for quite |
| 147 | some time. Additionally, if the KVM-enabled QEMU instance running on a |
| 148 | seattle host is using the `cortex-a57` CPU type, then querying `cortex-a57` |
| 149 | will work. |
| 150 | |
| 151 | Using CPU Features |
| 152 | ================== |
| 153 | |
| 154 | After determining which CPU features are available and supported for a |
| 155 | given CPU type, then they may be selectively enabled or disabled on the |
| 156 | QEMU command line with that CPU type:: |
| 157 | |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 158 | $ qemu-system-aarch64 -M virt -cpu max,pmu=off,sve=on,sve128=on,sve256=on |
Andrew Jones | e19afd5 | 2019-10-31 15:27:26 +0100 | [diff] [blame] | 159 | |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 160 | The example above disables the PMU and enables the first two SVE vector |
| 161 | lengths for the `max` CPU type. Note, the `sve=on` isn't actually |
| 162 | necessary, because, as we observed above with our probe of the `max` CPU |
| 163 | type, `sve` is already on by default. Also, based on our probe of |
| 164 | defaults, it would seem we need to disable many SVE vector lengths, rather |
| 165 | than only enabling the two we want. This isn't the case, because, as |
| 166 | disabling many SVE vector lengths would be quite verbose, the `sve<N>` CPU |
| 167 | properties have special semantics (see "SVE CPU Property Parsing |
| 168 | Semantics"). |
| 169 | |
Andrew Jones | dea101a | 2020-01-30 16:02:06 +0000 | [diff] [blame] | 170 | KVM VCPU Features |
| 171 | ================= |
| 172 | |
| 173 | KVM VCPU features are CPU features that are specific to KVM, such as |
| 174 | paravirt features or features that enable CPU virtualization extensions. |
| 175 | The features' CPU properties are only available when KVM is enabled and |
| 176 | are named with the prefix "kvm-". KVM VCPU features may be probed, |
| 177 | enabled, and disabled in the same way as other CPU features. Below is |
| 178 | the list of KVM VCPU features and their descriptions. |
| 179 | |
| 180 | kvm-no-adjvtime By default kvm-no-adjvtime is disabled. This |
| 181 | means that by default the virtual time |
Philippe Mathieu-Daudé | fa3236a | 2020-02-07 14:04:28 +0000 | [diff] [blame] | 182 | adjustment is enabled (vtime is not *not* |
Andrew Jones | dea101a | 2020-01-30 16:02:06 +0000 | [diff] [blame] | 183 | adjusted). |
| 184 | |
| 185 | When virtual time adjustment is enabled each |
| 186 | time the VM transitions back to running state |
| 187 | the VCPU's virtual counter is updated to ensure |
| 188 | stopped time is not counted. This avoids time |
| 189 | jumps surprising guest OSes and applications, |
| 190 | as long as they use the virtual counter for |
| 191 | timekeeping. However it has the side effect of |
| 192 | the virtual and physical counters diverging. |
| 193 | All timekeeping based on the virtual counter |
| 194 | will appear to lag behind any timekeeping that |
| 195 | does not subtract VM stopped time. The guest |
| 196 | may resynchronize its virtual counter with |
| 197 | other time sources as needed. |
| 198 | |
| 199 | Enable kvm-no-adjvtime to disable virtual time |
| 200 | adjustment, also restoring the legacy (pre-5.0) |
| 201 | behavior. |
| 202 | |
Andrew Jones | 68970d1 | 2020-10-01 08:17:18 +0200 | [diff] [blame] | 203 | kvm-steal-time Since v5.2, kvm-steal-time is enabled by |
| 204 | default when KVM is enabled, the feature is |
| 205 | supported, and the guest is 64-bit. |
| 206 | |
| 207 | When kvm-steal-time is enabled a 64-bit guest |
| 208 | can account for time its CPUs were not running |
| 209 | due to the host not scheduling the corresponding |
| 210 | VCPU threads. The accounting statistics may |
| 211 | influence the guest scheduler behavior and/or be |
| 212 | exposed to the guest userspace. |
| 213 | |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 214 | SVE CPU Properties |
| 215 | ================== |
| 216 | |
| 217 | There are two types of SVE CPU properties: `sve` and `sve<N>`. The first |
| 218 | is used to enable or disable the entire SVE feature, just as the `pmu` |
| 219 | CPU property completely enables or disables the PMU. The second type |
| 220 | is used to enable or disable specific vector lengths, where `N` is the |
| 221 | number of bits of the length. The `sve<N>` CPU properties have special |
| 222 | dependencies and constraints, see "SVE CPU Property Dependencies and |
| 223 | Constraints" below. Additionally, as we want all supported vector lengths |
| 224 | to be enabled by default, then, in order to avoid overly verbose command |
| 225 | lines (command lines full of `sve<N>=off`, for all `N` not wanted), we |
| 226 | provide the parsing semantics listed in "SVE CPU Property Parsing |
| 227 | Semantics". |
| 228 | |
| 229 | SVE CPU Property Dependencies and Constraints |
| 230 | --------------------------------------------- |
| 231 | |
| 232 | 1) At least one vector length must be enabled when `sve` is enabled. |
| 233 | |
Andrew Jones | 6fa8a37 | 2019-10-31 15:27:33 +0100 | [diff] [blame] | 234 | 2) If a vector length `N` is enabled, then, when KVM is enabled, all |
| 235 | smaller, host supported vector lengths must also be enabled. If |
| 236 | KVM is not enabled, then only all the smaller, power-of-two vector |
| 237 | lengths must be enabled. E.g. with KVM if the host supports all |
| 238 | vector lengths up to 512-bits (128, 256, 384, 512), then if `sve512` |
| 239 | is enabled, the 128-bit vector length, 256-bit vector length, and |
| 240 | 384-bit vector length must also be enabled. Without KVM, the 384-bit |
| 241 | vector length would not be required. |
| 242 | |
| 243 | 3) If KVM is enabled then only vector lengths that the host CPU type |
| 244 | support may be enabled. If SVE is not supported by the host, then |
| 245 | no `sve*` properties may be enabled. |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 246 | |
| 247 | SVE CPU Property Parsing Semantics |
| 248 | ---------------------------------- |
| 249 | |
| 250 | 1) If SVE is disabled (`sve=off`), then which SVE vector lengths |
| 251 | are enabled or disabled is irrelevant to the guest, as the entire |
| 252 | SVE feature is disabled and that disables all vector lengths for |
| 253 | the guest. However QEMU will still track any `sve<N>` CPU |
| 254 | properties provided by the user. If later an `sve=on` is provided, |
| 255 | then the guest will get only the enabled lengths. If no `sve=on` |
| 256 | is provided and there are explicitly enabled vector lengths, then |
| 257 | an error is generated. |
| 258 | |
| 259 | 2) If SVE is enabled (`sve=on`), but no `sve<N>` CPU properties are |
Andrew Jones | 6fa8a37 | 2019-10-31 15:27:33 +0100 | [diff] [blame] | 260 | provided, then all supported vector lengths are enabled, which when |
| 261 | KVM is not in use means including the non-power-of-two lengths, and, |
| 262 | when KVM is in use, it means all vector lengths supported by the host |
| 263 | processor. |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 264 | |
| 265 | 3) If SVE is enabled, then an error is generated when attempting to |
| 266 | disable the last enabled vector length (see constraint (1) of "SVE |
| 267 | CPU Property Dependencies and Constraints"). |
| 268 | |
| 269 | 4) If one or more vector lengths have been explicitly enabled and at |
| 270 | at least one of the dependency lengths of the maximum enabled length |
| 271 | has been explicitly disabled, then an error is generated (see |
| 272 | constraint (2) of "SVE CPU Property Dependencies and Constraints"). |
| 273 | |
Andrew Jones | 6fa8a37 | 2019-10-31 15:27:33 +0100 | [diff] [blame] | 274 | 5) When KVM is enabled, if the host does not support SVE, then an error |
| 275 | is generated when attempting to enable any `sve*` properties (see |
| 276 | constraint (3) of "SVE CPU Property Dependencies and Constraints"). |
| 277 | |
| 278 | 6) When KVM is enabled, if the host does support SVE, then an error is |
| 279 | generated when attempting to enable any vector lengths not supported |
| 280 | by the host (see constraint (3) of "SVE CPU Property Dependencies and |
| 281 | Constraints"). |
| 282 | |
| 283 | 7) If one or more `sve<N>` CPU properties are set `off`, but no `sve<N>`, |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 284 | CPU properties are set `on`, then the specified vector lengths are |
| 285 | disabled but the default for any unspecified lengths remains enabled. |
Andrew Jones | 6fa8a37 | 2019-10-31 15:27:33 +0100 | [diff] [blame] | 286 | When KVM is not enabled, disabling a power-of-two vector length also |
| 287 | disables all vector lengths larger than the power-of-two length. |
| 288 | When KVM is enabled, then disabling any supported vector length also |
| 289 | disables all larger vector lengths (see constraint (2) of "SVE CPU |
| 290 | Property Dependencies and Constraints"). |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 291 | |
Andrew Jones | 6fa8a37 | 2019-10-31 15:27:33 +0100 | [diff] [blame] | 292 | 8) If one or more `sve<N>` CPU properties are set to `on`, then they |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 293 | are enabled and all unspecified lengths default to disabled, except |
| 294 | for the required lengths per constraint (2) of "SVE CPU Property |
| 295 | Dependencies and Constraints", which will even be auto-enabled if |
| 296 | they were not explicitly enabled. |
| 297 | |
Andrew Jones | 6fa8a37 | 2019-10-31 15:27:33 +0100 | [diff] [blame] | 298 | 9) If SVE was disabled (`sve=off`), allowing all vector lengths to be |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 299 | explicitly disabled (i.e. avoiding the error specified in (3) of |
| 300 | "SVE CPU Property Parsing Semantics"), then if later an `sve=on` is |
| 301 | provided an error will be generated. To avoid this error, one must |
| 302 | enable at least one vector length prior to enabling SVE. |
| 303 | |
| 304 | SVE CPU Property Examples |
| 305 | ------------------------- |
| 306 | |
| 307 | 1) Disable SVE:: |
| 308 | |
| 309 | $ qemu-system-aarch64 -M virt -cpu max,sve=off |
| 310 | |
| 311 | 2) Implicitly enable all vector lengths for the `max` CPU type:: |
| 312 | |
| 313 | $ qemu-system-aarch64 -M virt -cpu max |
| 314 | |
Andrew Jones | 87014c6 | 2019-10-31 15:27:34 +0100 | [diff] [blame] | 315 | 3) When KVM is enabled, implicitly enable all host CPU supported vector |
| 316 | lengths with the `host` CPU type:: |
| 317 | |
| 318 | $ qemu-system-aarch64 -M virt,accel=kvm -cpu host |
| 319 | |
| 320 | 4) Only enable the 128-bit vector length:: |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 321 | |
| 322 | $ qemu-system-aarch64 -M virt -cpu max,sve128=on |
| 323 | |
Andrew Jones | 87014c6 | 2019-10-31 15:27:34 +0100 | [diff] [blame] | 324 | 5) Disable the 512-bit vector length and all larger vector lengths, |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 325 | since 512 is a power-of-two. This results in all the smaller, |
| 326 | uninitialized lengths (128, 256, and 384) defaulting to enabled:: |
| 327 | |
| 328 | $ qemu-system-aarch64 -M virt -cpu max,sve512=off |
| 329 | |
Andrew Jones | 87014c6 | 2019-10-31 15:27:34 +0100 | [diff] [blame] | 330 | 6) Enable the 128-bit, 256-bit, and 512-bit vector lengths:: |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 331 | |
| 332 | $ qemu-system-aarch64 -M virt -cpu max,sve128=on,sve256=on,sve512=on |
| 333 | |
Andrew Jones | 87014c6 | 2019-10-31 15:27:34 +0100 | [diff] [blame] | 334 | 7) The same as (6), but since the 128-bit and 256-bit vector |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 335 | lengths are required for the 512-bit vector length to be enabled, |
| 336 | then allow them to be auto-enabled:: |
| 337 | |
| 338 | $ qemu-system-aarch64 -M virt -cpu max,sve512=on |
| 339 | |
Andrew Jones | 87014c6 | 2019-10-31 15:27:34 +0100 | [diff] [blame] | 340 | 8) Do the same as (7), but by first disabling SVE and then re-enabling it:: |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 341 | |
| 342 | $ qemu-system-aarch64 -M virt -cpu max,sve=off,sve512=on,sve=on |
| 343 | |
Andrew Jones | 87014c6 | 2019-10-31 15:27:34 +0100 | [diff] [blame] | 344 | 9) Force errors regarding the last vector length:: |
Andrew Jones | 0df9142 | 2019-10-31 15:27:29 +0100 | [diff] [blame] | 345 | |
| 346 | $ qemu-system-aarch64 -M virt -cpu max,sve128=off |
| 347 | $ qemu-system-aarch64 -M virt -cpu max,sve=off,sve128=off,sve=on |
| 348 | |
| 349 | SVE CPU Property Recommendations |
| 350 | -------------------------------- |
| 351 | |
| 352 | The examples in "SVE CPU Property Examples" exhibit many ways to select |
| 353 | vector lengths which developers may find useful in order to avoid overly |
| 354 | verbose command lines. However, the recommended way to select vector |
| 355 | lengths is to explicitly enable each desired length. Therefore only |
Andrew Jones | 87014c6 | 2019-10-31 15:27:34 +0100 | [diff] [blame] | 356 | example's (1), (4), and (6) exhibit recommended uses of the properties. |
Andrew Jones | e19afd5 | 2019-10-31 15:27:26 +0100 | [diff] [blame] | 357 | |