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
