> On 2 Nov 2022, at 09:11, Christian Lindig <christian.lin...@citrix.com> wrote:
> 
> 
> 
>> On 1 Nov 2022, at 17:59, Edwin Török <edvin.to...@citrix.com> wrote:
>> 
>> 
>> Edwin Török (2):
>> xenctrl.ml: make domain_getinfolist tail recursive
>> xenctrl: use larger chunksize in domain_getinfolist
>> 
>> tools/ocaml/libs/xc/xenctrl.ml | 25 ++++++++++++++++++-------
>> 1 file changed, 18 insertions(+), 7 deletions(-)
> 
> Acked-by: Christian Lindig <christian.lin...@citrix.com>
> 
> 
>> It was calling the Xen domainfolist hypercall N/2 times.
>> Optimize this such that it is called at most 2 times during normal use.
>> 
>> Implement a tail recursive `rev_concat` equivalent to `concat |> rev`,
>> and use it instead of calling `@` multiple times.
> 
> Are there any assurances about the order in elements returned by 
> domain_getinfolist? I understand that the change maintains the current 
> behaviour but are we even required to maintain that order? Because otherwise 
> we could return the reverse list and save more work.


After some discussion with Andrew Cooper apparently the xenctrl API is broken 
and cannot be used safely as is, so I'll be rewriting this patch.
Domids can be assigned randomly, or toolstacks can set a custom domid, so it is 
not guaranteed that new domids always show up as higher numbers,
and the only safe way to use infolist is to either request 1 domid, or request 
them all (domids are 15-bit, so 32768).
Anything else is prone to race conditions and might give you an inconsistent 
snapshot.

This is probably better fixed by changing the prototype of the C function in 
xenctrl to not take a count to force updating all callers
(the callers in the 'xl' toolstack are just as buggy as the one in this OCaml 
binding, and probably better to fix the API in xenctrl than working around the 
race condition in each caller).

Stay tuned for more patches...

Best regards,
--Edwin

Reply via email to