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

[Jürgen Groß <jgross@xxxxxxxx>]

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).


Juergen