Re: [PATCH 1/2] tools/ocaml: Fix crash in Xenctrl.domain_getinfo{,list} on ARM

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 29/07/2026 7:03 am, Jan Beulich wrote:
> On 28.07.2026 17:48, Andrew Cooper wrote:
>> @@ -452,16 +456,17 @@ static value alloc_domaininfo(xc_domaininfo_t * info)
>>              (info->arch_config.emulation_flags);
>>  
>>      /* xen_x86_arch_domainconfig */
>> -    x86_arch_config = caml_alloc_tuple(1);
>> -    Store_field(x86_arch_config, 0, emul_list);
>> +    arch_config = caml_alloc_tuple(1);
>> +    Field(arch_config, 0) = emul_list;
>>  
>> -    /* arch_config: arch_domainconfig */
>> -    arch_config = caml_alloc_small(1, 1);
>> -
>> -    Store_field(arch_config, 0, x86_arch_config);
>> -
>> -    Store_field(result, 16, arch_config);
>>  #endif
>> +    if (tag < 0)
>> +            caml_failwith("Unimplemented architecutre in 
>> alloc_domaininfo()");
> As I now ended up looking here as well (to determine whether this series will
> want backporting): s/architecutre/architecture/ .

Fixed.  There was also a typo in the commit message.

> As to backporting: Both patches may want to have Fixes: tags?

Hmm, yes.

Technically, Fixes: 81838c9067ab ("ocaml: fix arm build") was the one
which caused the pointer not to be filled in, but it was a build fix for
Fixes: 9d683b5e375d ("tools/ocaml: Expose arch_config in domaininfo")
which was the main one intending to produce an arch_config

I guess I should go with both tags.

Patch 2 is interesting as well, because really it's both tags too.  In
my main first patch (if it had compiled), we would have ended up handing
an xen_x86_arch_domainconfig back when an ARM toolstack asked.

Fixed up locally.

~Andrew