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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 09/26/2017 12:10 AM, 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,
> 
> 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?
> 
> 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?
> 
> 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.
> 
> Thoughts?

One thing we've been talking about for a long time is having more of a
formal process for getting features into the 'supported' state; and one
of the key criteria for that was to make sure that the feature was
getting regular testing somewhere (preferably in osstest, but at least
*somewhere*).

A lot of these features we have no idea how much testing they're getting
or even if they work reliably; so we put them in 'experimental' or
'preview' by default, until someone who is working on those features
wants to argue otherwise.  If Meng (or someone) wanted RTDS to be
considered 'supported', he could come to us and ask for it to be
considered 'supported'; and we can discuss what criteria we'd use to
decide whether to change it or not.

And of course, all of this (both the "ask for it to be considered
supported" and "make sure it's regularly tested") is really just a proxy
for "How much do people care about this feature".  If people care enough
about the feature to notice that it's listed as 'experimental' and set
up regular testing, then we should care enough to give it security
support.  If nobody cares enough about the feature to even notice it's
not listed as 'supported', or to give it regular testing (again, not
even necessarily in osstest), then I think we're justified in not caring
enough to give it security support.

As Dario said, the null scheduler could do with just getting into osstest.

 -George

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