On 11.12.2024 20:49, Daniel P. Smith wrote: > On 12/2/24 07:19, Jan Beulich wrote: >> On 23.11.2024 19:20, Daniel P. Smith wrote: >>> --- a/xen/arch/x86/dom0_build.c >>> +++ b/xen/arch/x86/dom0_build.c >>> @@ -617,6 +617,9 @@ int __init construct_dom0(struct boot_domain *bd) >>> if ( !get_memsize(&dom0_max_size, LONG_MAX) && bd->max_pages ) >>> dom0_size.nr_pages = bd->max_pages; >>> >>> + if ( opt_dom0_max_vcpus_max == UINT_MAX && bd->max_vcpus ) >>> + opt_dom0_max_vcpus_max = bd->max_vcpus; >> >> Isn't this kind of backwards? I.e. aren't you meaning to move us towards >> boot-domains? > > Prior to domain builder, available construction parameters for dom0 were > exposed as command line parameters. This allowed for boot-time > adjustments to the parameters. With domain builder, there are now two > sources for dom0 construction parameters. Those coming from the device > tree and those coming from the command line. For most x86 platforms, the > device tree parameters can only be constructed prior to booting Xen. > Whereas the command line parameters allow boot-time adjustments, at > least for dom0. That is the thinking at least. Now if there is interest > in being able to retire the command line options, that would definitely > simplify things.
No, retiring command line options is out of question imo. Yet that also wasn't my point. Instead I was wondering why we wouldn't make bd->* the ultimate source of truth. However, ... >> Also, what about the counterpart opt_dom0_max_vcpus_min? That wants to be >> controllable from DT too, I would think? > > Yes, in theory we will eventually be able to do requested/min/max as > well as cpu pinning/affinity. For now it was requested we focus on > implementing only requested vcpus. ... that's pretty much only a reasonable option if these were converted at the same time, to avoid becoming inconsistent for perhaps an extended period of time. Jan
