Re: [PATCH 1/2] tools/ocaml: Fix crash in Xenctrl.domain_getinfo{,list} on ARM
Andrew Cooper <[email protected]> Wed, 29 Jul 2026 09:51:26 +0100
| Newsgroups | gmane.comp.emulators.xen.devel |
|---|---|
| Message-ID | <[email protected]> |
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