Re: [xen-unstable test] 153602: regressions - FAIL

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.09.2020 08:38, Jürgen Groß wrote:
> On 04.09.20 08:32, Jan Beulich wrote:
>> On 03.09.2020 18:17, Ian Jackson wrote:
>>> Jan Beulich writes ("Re: [xen-unstable test] 153602: regressions - FAIL"):
>>>> On 03.09.2020 12:24, osstest service owner wrote:
>>>>> flight 153602 xen-unstable real [real]
>>>>> http://logs.test-lab.xenproject.org/osstest/logs/153602/
>>>>>
>>>>> Regressions :-(
>>>>>
>>>>> Tests which did not succeed and are blocking,
>>>>> including tests which could not be run:
>>>>>   test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 
>>>>> debian-hvm-install fail REGR. vs. 152877
>>>>>   test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 
>>>>> debian-hvm-install fail REGR. vs. 152877
>>>>
>>>> While at least the hypervisor logs don't provide clear indication
>>>> (and I don't know where else to look among the files osstest
>>>> provides) I can't help thinking that stubdom apparently
>>>> crashing is still fallout from the mini-os changes (and no-one
>>>> really looks to care). In particular I think that this
>>>
>>> I haven't looked at this in detail but I notice that I am having
>>> build failures.
>>>
>>> Prior to e013e8514389 "config: use mini-os master for unstable", the
>>> version of mini-os used for builds was controlled by xen.git's
>>> Config.mk.
>>>
>>> Since then it has been mini-os master.  NB there is no push gate for
>>> mini-os.  IIRC we discussed this at the time and it was thought that
>>> breakage due to mini-os would be unlikely.
>>>
>>> To unblock development in xen.git I suggest reverting the minios part
>>> of 165f3afbfc3d "Config.mk: Unnail versions (for unstable branch)",
>>> choosing some known-working version of minios to put in Config.mk.
>>
>> Afaict this would still not work, due to 8d990807ec2c ("stubdom/grub:
>> update init_netfront() call for mini-os"). The dependencies between
>> the two trees aren't helpful at all in a case like this one.
> 
> This is clearly a problem of the mini-os private interfaces used by
> stubdom/grub. The clean solution here would be either to add a stable
> ABI to mini-os usable by stubdom/grub (and probably others in similar
> cases) in order to avoid such issues, or to have feature defines like
> for libxl in order to be able to specify to use the old interfaces of
> mini-os by stubdoms (which could be removed after all users having been
> switched to the new interfaces).

Actually, with also reverting 8d990807ec2c in the main tree (along with
effectively reverting e013e8514389, which comes down to the same as Ian
suggested for 165f3afbfc3d), and with its future re-installment at the
same time bumping the mini-os commit to use, things ought to work I
would think. That would then be the same model again as used for
qemu-trad.

Jan