Re: [Xen-devel] [qemu-upstream-4.11-testing test] 136184: regressions - FAIL

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Stefano Stabellini writes ("Re: [Xen-devel] [qemu-upstream-4.11-testing test] 
136184: regressions - FAIL"):
> I agree with you it would be desirable to test both LIVEPATCH and
> non-LIVEPATCH, and I understand about limitation of resources and test
> matrix explosion.
> 
> Given the chance, I think it would be better if we had an explicit test
> about LIVEPATCH rather than a "hidden" enablement of it within another
> different test. Or maybe just call it out explicitly, renaming the test
> run to qemu-upstream-livepatch or something like that. In any case, I'll
> leave it to you.

I think maybe you have misunderstood ?

The thing that triggers this bug, here, is *compiling* Xen with
CONFIG_LIVEPATCH *disabled*.

So, in fact, if it is a hidden anything, it is a hidden *dis*ablement
of a feature which is deliberately only compiled in, and only tested
on, tests of the xen-* branches.

That *disabling* this feature would cause a regression is surprising,
and I think this is only the case because Xen only works by accident
on these boxes ?  (Considering the discussion of ARM ARM violations.)

To make it an "explicit" test as you suggest would involve compiling
Xen an additional time.  I guess that would actually be changing some
tests on xen-* branches to a version of Xen compiled *without*
livepatch.  Right now we build

most other branches
   Xen amd64  with XSM   no livepatch
   Xen armhf  no   XSM   no livepatch
   Xen arm64  with XSM   no livepatch

xen-* branches
   Xen amd64  with XSM   with livepatch
   Xen armhf  no   XSM   with livepatch
   Xen arm64  with XSM   with livepatch

What without-livepatch build should be added to the xen-* branches ?
And in which tests should it replace the existing with-livepatch
builds ?  Should I just pick one or two apparently at random ?

NB that I doubt the livepatch maintainers have much of an opinion
here.  We would normally expect that compiling in livepatching might
break something but that compiling it out would be fine.  So the
current situation is good from that point of view and we might even
worry that changing some of the existing tests to not have
livepatching compiled in might miss some actual livepatch-related
bugs.  My normal practice is to try to enable as much as is relevant
and might break things.

But what we have here is *not* a livepatch-related bug.  It has
nothing to do with livepatch.  It is just that by luck, compiling Xen
*with* livepatching somehow masks the random failure, presumably by
changing exact orderings and timings of memory accesses etc.

Does that make sense ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel