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

[Robert VanVossen <robert.vanvossen@xxxxxxxxxxxxxxx>]

On 9/26/2017 3:12 AM, Dario Faggioli wrote:
> [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?
>

Yes, we do still use the ARINC653 scheduler. Since it is so simple, it hasn't
really needed any modifications in the last couple years.

We are not really sure what kind of feedback you are looking from us in regards
to marking it sec-supported, but would be happy to try and answer any questions.
If you have any specific questions or requests, we can discuss it internally and
get back to you.

Thanks,
Robbie VanVossen

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