On Tue, 5 Jul 2022 at 15:37, Ilya Leoshkevich <i...@linux.ibm.com> wrote:
>
> On Tue, 2022-07-05 at 14:57 +0100, Peter Maydell wrote:
> > On Tue, 5 Jul 2022 at 14:04, Daniel P. Berrangé <berra...@redhat.com>
> > wrote:
> > > If we put this job in QEMU CI someone will have to be able to
> > > interpret the results when it fails.
> >
> > In particular since this is qemu-user, the answer is probably
> > at least some of the time going to be "oh, well, qemu-user isn't
> > reliable
> > if you do complicated things in the guest". I'd be pretty wary of our
> > having
> > a "pass a big complicated guest code test suite under linux-user
> > mode"
> > in the CI path.
> Actually exercising qemu-user is one of the goals here: just as an
> example, one of the things that the test suite found was commit
> 9a12adc704f9 ("linux-user/s390x: Fix unwinding from signal handlers"),
> so it's not only about the ISA.
>
> At least for s390x, we've noticed that various projects use
> qemu-user-based setups in their CI (either calling it explicitly, or
> via binfmt-misc), and we would like these workflows to be reliable,
> even if they try complicated (within reason) things there.
I also would like them to be reliable. But I don't think
*testing* these things is the difficulty: it is having
people who are willing to spend time on the often quite
difficult tasks of identifying why something intermittently
fails and doing the necessary design and implementation work
to correct the problem. Sometimes this is easy (as in the
s390 regression above) but quite often it is not (eg when
multiple threads are in use, or the guest wants to do
something complicated with clone(), etc).
thanks
-- PMM
