Re: [PATCH 5/5] sched/arinc653: Implement CAST-32A multicore scheduling

[Jeff Kubascik <jeff.kubascik@xxxxxxxxxxxxxxx>]

On 9/17/2020 1:57 PM, Stewart Hildebrand wrote:
> On Thursday, September 17, 2020 12:19 PM, Andrew Cooper wrote:
>> On 17/09/2020 15:57, Stewart Hildebrand wrote:
>>> On Thursday, September 17, 2020 10:43 AM, Andrew Cooper wrote:
>>>> On 16/09/2020 19:18, Jeff Kubascik wrote:
>>>>> +/*
>>>>> + * A handle with all zeros represents domain 0 if present, otherwise 
>>>>> idle UNIT
>>>>> + */
>>>>> +#define DOM0_HANDLE ((const xen_domain_handle_t){0})
>>>> This isn't accurate.
>>>>
>>>> There are systems where dom0 doesn't have a zero UUID (XenServer for
>>>> one), and its easy to create domU's which have a zero UUID.  They are
>>>> not unique, and can be changed at any time during the running of the VM.
>>>>
>>>> If you need a unique identifier, then use domid's.
>>>>
>>>> I can't see any legitimate need for the scheduler to handle the UUID at 
>>>> all.
>>> We tried switching it to domid at one point in the past, but the problem 
>>> was that when a domU reboots (destroy/create) the domid
>> increments, so the schedule would have to be reinstantiated.
>>
>> How are settings specified?  If they're manually while the domain is
>> running, then I'd argue that is a user bug.
> 
> It could be either prior to domain creation or after. The user needs to know 
> the UUID (or domid, if we were to switch to domid) of the domain(s) to be 
> scheduled.
> 
> We typically use this utility [2] which relies on tools/libxc/xc_arinc653.c
> 
> [2] https://github.com/dornerworks/a653_sched
> 
>>
>> If the settings are specified in the VM's configuration file, and they
>> aren't reapplied on reboot, then that is a toolstack bug.
>>
>>> At least that was the case before a recent patch series allowing to specify 
>>> domid [1], but Jeff developed this CAST-32A series prior to
>> that. The UUID can be specified in the .cfg file, allowing domUs to reboot 
>> and come back up with the same UUID.
>>
>> The UUID can and does change at runtime in some cases, when you get into
>> more complicated lifecycle scenarios such as localhost live migration,
>> and/or VM Fork/CoW.
>>
>>
>> Having scheduler settings remembered by UUID, in the lower layers of the
>> hypervisor, feels like a layering violation.  It might work for your
>> specific usecase, but it feels like it is papering over the underlying
>> bug, and it is incompatible with other usage scenarios within Xen.
> 
> These are all good points. I'd welcome a switch to domid, but I feel it 
> should be a separate patch or series.

Is there a configuration file or xl create option to specify the domid? I'm
unable to find the mentioned patch series, or anything in the documentation.

And agreed. The current implementation of the scheduler uses the UUID approach.
Switching to a domid approach would be better suited for a separate series.

-Jeff