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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

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.

~Andrew