> On 20 Mar 2023, at 09:13, Jan Beulich <jbeul...@suse.com> wrote: > > On 17.03.2023 14:19, Luca Fancellu wrote: >> --- a/docs/misc/xen-command-line.pandoc >> +++ b/docs/misc/xen-command-line.pandoc >> @@ -1005,6 +1005,19 @@ restrictions set up here. Note that the values to be >> specified here are >> ACPI PXM ones, not Xen internal node numbers. `relaxed` sets up vCPU >> affinities to prefer but be not limited to the specified node(s). >> >> +### dom0_sve (arm) >> +> `= <integer>` >> + >> +> Default: `0` >> + >> +Enable arm SVE usage for Dom0 domain and sets the maximum SVE vector length. >> +Values above 0 means feature is enabled for Dom0, otherwise feature is >> disabled. >> +Possible values are from 0 to maximum 2048, being multiple of 128, that >> will be >> +the maximum vector length. >> +Please note that the platform can supports a lower value, if the requested >> value >> +is above the supported one, the domain creation will fail and the system >> will >> +stop. >> + >> ### dom0_vcpus_pin >>> `= <boolean>` > > I'd like to raise the question of proliferation of top-level command > line options controlling Dom0. In x86 we've specifically started to use > "dom0=" as the one top-level option where almost all new controls should > be added as sub-options. > > _If_ a top-level option is indeed preferred, then please avoid the use > of an underscore in its name, when a dash does fine.
Yes, maybe something like dom0=sve=<VL>,[...] is nice for new possible incoming features, While I was browsing the code, I spotted a possible bug in x86/dom0_build.c, in parse_dom0_param(...) if an option is not recognised we set rc = -EINVAL, but we don’t stop the loop and we continue to parse. Is it the intended behaviour? > > Jan
