| Message ID | 72b98382-34ba-6e9d-c90e-c913dfe66258@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] firmware/shim: UNSUPPORTED=n | expand |
On Wed, May 26, 2021 at 09:37:37AM +0200, Jan Beulich wrote: > We shouldn't default to include any unsupported code in the shim. Mark > the setting as off, replacing the ARGO specification. This points out > anomalies with the scheduler configuration: Unsupported schedulers > better don't default to Y in release builds (like is already the case > for ARINC653). Without at least the SCHED_NULL adjustments, the shim > would suddenly build with RTDS as its default scheduler. > > As a result, the SCHED_NULL setting can also be dropped from defconfig. > > Clearly with the shim defaulting to it, SCHED_NULL must be supported at > least there. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > Acked-by: Roger Pau Monné <roger.pau@citrix.com> > --- > v2: Also drop SCHED_NULL setting from defconfig. Make SCHED_NULL the > default when PV_SHIM_EXCLUSIVE. > --- > I'm certainly open to consider alterations on the sched/Kconfig > adjustments, but _something_ needs to be done there. In particular I > was puzzled to find the NULL scheduler marked unsupported. Clearly with > the shim defaulting to it, it must be supported at least there. > > In a PV_SHIM (but perhaps !PV_SHIM_EXCLUSIVE) build with the build-time > default not being SCHED_NULL, when actually running as shim I can't seem > to see how the null scheduler would get chosen as the default > nevertheless. Shouldn't this happen (in the absence of a command line > override)? I wondered the same yesterday and got to the conclusion that it's then the duty of the user to add pvshim_extra="sched=null" to the config file. I think it would indeed be useful to select the null scheduler at runtime if booting in shim mode and null is present, but then we would be ignoring the default scheduler selection made in Kconfig, which could be confusing. It's also confusing that the scheduler that gets set as the default when shim exclusive is selected is not available to enable/disable: [*] Credit scheduler support (NEW) [*] Credit2 scheduler support (NEW) Default Scheduler? (Null Scheduler) ---> Thanks, Roger.
On 26.05.2021 10:27, Roger Pau Monné wrote:> It's also confusing that the scheduler that gets set as the default> when shim exclusive is selected is not available to enable/disable:> > [*] Credit scheduler support (NEW)> [*] Credit2 scheduler support (NEW)> Default Scheduler? (Null Scheduler) ---> I don't view this as confusing - we want the null scheduler there in this case, unconditionally. But yes, the prompt's condition could of course also have "PV_SHIM || " added. Jan
On Wed, 2021-05-26 at 09:37 +0200, Jan Beulich wrote: > We shouldn't default to include any unsupported code in the shim. Mark > the setting as off, replacing the ARGO specification. This points out > anomalies with the scheduler configuration: Unsupported schedulers > better don't default to Y in release builds (like is already the case > for ARINC653). Without at least the SCHED_NULL adjustments, the shim > would suddenly build with RTDS as its default scheduler. > > As a result, the SCHED_NULL setting can also be dropped from defconfig. > > Clearly with the shim defaulting to it, SCHED_NULL must be supported at > least there. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > Acked-by: Roger Pau Monné <roger.pau@citrix.com> > Reviewed-by: Dario Faggioli <dfaggioli@suse.com> > --- > v2: Also drop SCHED_NULL setting from defconfig. Make SCHED_NULL the > default when PV_SHIM_EXCLUSIVE. > --- > I'm certainly open to consider alterations on the sched/Kconfig > adjustments, but _something_ needs to be done there. In particular I > was puzzled to find the NULL scheduler marked unsupported. Clearly with > the shim defaulting to it, it must be supported at least there. > I think null both should and can be supported. There's an outstanding bug [1], which we may want to finally fix before declaring it as such. More important IMO, we should add an OSSTest test for it. The latter may be tricky, as the hypervisor configuration of such test needs to be host specific. In fact, we need to know how many CPUs we have on the host, and configure Xen to give only a subset of them to dom0 (or offline a few, after boot), as well as avoid running on 1 (and problably also 2) CPUs hosts... or we won't be able to start guests and/or do local migration jobs. I can try to put something together, but I don't currently have an OSSTest development environment up and running any longer, so it may take a couple of iterations... [1] https://lists.xenproject.org/archives/html/xen-devel/2021-01/msg01634.html > --- a/xen/common/sched/Kconfig > +++ b/xen/common/sched/Kconfig > @@ -16,7 +16,7 @@ config SCHED_CREDIT2 > > config SCHED_RTDS > bool "RTDS scheduler support (UNSUPPORTED)" if UNSUPPORTED > - default y > + default DEBUG > ---help--- > The RTDS scheduler is a soft and firm real-time scheduler for > multicore, targeted for embedded, automotive, graphics and > gaming > This is fine for me, for now. That being said, if remember correctly, it should have all the features that we said we wanted to it to have for declaring supported... Is anyone of the embedded/safety/automotive/edge users and downstreams interested interested on helping making RTDS first class citizen? And, if yes, what's the path toward that? Thanks and Regards
Dario Faggioli writes ("Re: [PATCH v2] firmware/shim: UNSUPPORTED=n"):
> I can try to put something together, but I don't currently have an
> OSSTest development environment up and running any longer, so it may
> take a couple of iterations...
(bit late with this but)
You could use your account on the Xen Project colo. Let me know if
you need pointers or anything resetting.
Regards,
Ian.
--- a/SUPPORT.md +++ b/SUPPORT.md @@ -351,9 +351,10 @@ Currently only single-vcpu domains are s A very simple, very static scheduling policy that always schedules the same vCPU(s) on the same pCPU(s). It is designed for maximum determinism and minimum overhead -on embedded platforms. +on embedded platforms and the x86 PV shim. Status: Experimental + Status, x86/shim: Supported ### NUMA scheduler affinity --- a/xen/arch/x86/configs/pvshim_defconfig +++ b/xen/arch/x86/configs/pvshim_defconfig @@ -6,7 +6,6 @@ CONFIG_PV_SHIM=y CONFIG_PV_SHIM_EXCLUSIVE=y CONFIG_NR_CPUS=32 CONFIG_EXPERT=y -CONFIG_SCHED_NULL=y # Disable features not used by the PV shim # CONFIG_XEN_SHSTK is not set # CONFIG_GRANT_TABLE is not set @@ -15,7 +14,7 @@ CONFIG_SCHED_NULL=y # CONFIG_KEXEC is not set # CONFIG_XENOPROF is not set # CONFIG_XSM is not set -# CONFIG_ARGO is not set +# CONFIG_UNSUPPORTED is not set # CONFIG_SCHED_CREDIT is not set # CONFIG_SCHED_CREDIT2 is not set # CONFIG_SCHED_RTDS is not set --- a/xen/common/sched/Kconfig +++ b/xen/common/sched/Kconfig @@ -16,7 +16,7 @@ config SCHED_CREDIT2 config SCHED_RTDS bool "RTDS scheduler support (UNSUPPORTED)" if UNSUPPORTED - default y + default DEBUG ---help--- The RTDS scheduler is a soft and firm real-time scheduler for multicore, targeted for embedded, automotive, graphics and gaming @@ -31,7 +31,7 @@ config SCHED_ARINC653 config SCHED_NULL bool "Null scheduler support (UNSUPPORTED)" if UNSUPPORTED - default y + default PV_SHIM || DEBUG ---help--- The null scheduler is a static, zero overhead scheduler, for when there always are less vCPUs than pCPUs, typically @@ -39,6 +39,7 @@ config SCHED_NULL choice prompt "Default Scheduler?" + default SCHED_NULL_DEFAULT if PV_SHIM_EXCLUSIVE default SCHED_CREDIT2_DEFAULT config SCHED_CREDIT_DEFAULT