Re: [PATCH v2] firmware/shim: UNSUPPORTED=n

[Dario Faggioli <dfaggioli@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 3204 bytes --]

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, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]