xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Dario Faggioli <dfaggioli@suse.com>
To: Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>,
	"George Dunlap" <george.dunlap@citrix.com>
Subject: Re: [PATCH v2] firmware/shim: UNSUPPORTED=n
Date: Thu, 27 May 2021 08:49:40 +0200	[thread overview]
Message-ID: <b1f53cd19ed65eec756d20fdec45c2c5cf79d0d8.camel@suse.com> (raw)
In-Reply-To: <72b98382-34ba-6e9d-c90e-c913dfe66258@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 --]

  parent reply	other threads:[~2021-05-27  6:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-30 14:39 [PATCH 0/3] firmware/shim: build adjustments Jan Beulich
2021-04-30 14:43 ` [PATCH 1/3] firmware/shim: update linkfarm exclusions Jan Beulich
2021-05-25 14:12   ` Roger Pau Monné
2021-04-30 14:44 ` [PATCH 2/3] firmware/shim: drop XEN_CONFIG_EXPERT uses Jan Beulich
2021-05-25 14:14   ` Roger Pau Monné
2021-05-25 15:14     ` Jan Beulich
2021-04-30 14:45 ` [PATCH 3/3] firmware/shim: UNSUPPORTED=n Jan Beulich
2021-05-25 14:39   ` Roger Pau Monné
2021-05-25 15:21     ` Jan Beulich
2021-05-25 15:51       ` Roger Pau Monné
2021-05-25 15:54         ` Jan Beulich
2021-05-25 11:10 ` Ping: [PATCH 0/3] firmware/shim: build adjustments Jan Beulich
2021-05-26  7:37 ` [PATCH v2] firmware/shim: UNSUPPORTED=n Jan Beulich
2021-05-26  8:27   ` Roger Pau Monné
2021-05-26  8:31     ` Jan Beulich
2021-05-27  6:49   ` Dario Faggioli [this message]
2021-06-02 11:57     ` Ian Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b1f53cd19ed65eec756d20fdec45c2c5cf79d0d8.camel@suse.com \
    --to=dfaggioli@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).