Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

[Cc-list modified by removing someone and adding someone else]

On Mon, 2017-09-25 at 16:10 -0700, Stefano Stabellini wrote:
> On Mon, 11 Sep 2017, George Dunlap wrote:
> > +### RTDS based Scheduler
> > +
> > +    Status: Experimental
> > +
> > +A soft real-time CPU scheduler built to provide guaranteed CPU
> > capacity to guest VMs on SMP hosts
> > +
> > +### ARINC653 Scheduler
> > +
> > +    Status: Supported, Not security supported
> > +
> > +A periodically repeating fixed timeslice scheduler. Multicore
> > support is not yet implemented.
> > +
> > +### Null Scheduler
> > +
> > +    Status: Experimental
> > +
> > +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.
> 
> Hi all,
> 
Hey!

> I have just noticed that none of the non-credit schedulers are
> security
> supported. Would it make sense to try to support at least one of
> them?
> 
Yes, that indeed would be great.

> For example, RTDS is not new and Dario is co-maintaining it. It is
> currently marked as Supported in the MAINTAINERS file. Is it really
> fair
> to mark it as "Experimental" in SUPPORT.md?
> 
True, but there still one small missing piece in RTDS, before I'd feel
comfortable about telling people "here, it's ready, use it at will",
which is the work conserving mode.

There are patches out for this, and they were posted before last
posting date, so, in theory, they still can go in 4.10.

> The Null scheduler was new when we started this discussion, but now
> that
> Xen 4.10 is entering code freeze, Null scheduler is not so new
> anymore.
> We didn't get any bug reports during the 4.10 development window. By
> the
> time this document is accepted and Xen 4.10 is out, Null could be a
> candidate for "Supported" too.
> 
Yes, especially considering how simple it is, there should be no big
issues preventing that to happen.

There's one thing, though: it's not tested in OSSTest. I can actually
try to have a quick look about creating a job that does that (I mean
like today).

The trickiest part is the need to limit the number of Dom0 vCPUs, to a
number that would allow the creation and the local migration of guests
(considering that the number of pCPUs of the testbox in the MA colo
varies, and that we have some ARM boards with like 1 or 2 CPUs).


Actually, the best candidate for gaining security support, is IMO
ARINC. Code is also rather simple and "stable" (hasn't changed in the
last... years!) and it's used by DornerWorks' people for some of their
projects (I think?). It's also not tested in OSSTest, though, and
considering how special purpose it is, I think we're not totally
comfortable marking it as Sec-Supported, without feedback from the
maintainers.

George, Josh, Robert?

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel