From: Ian Jackson <ian.jackson@citrix.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Anthony Perard <anthony.perard@citrix.com>,
xen-devel <xen-devel@lists.xenproject.org>,
Julien Grall <julien.grall@arm.com>,
Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [qemu-upstream-4.11-testing test] 136184: regressions - FAIL
Date: Tue, 4 Jun 2019 19:27:47 +0100 [thread overview]
Message-ID: <23798.47139.259170.371610@mariner.uk.xensource.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1906041059430.14041@sstabellini-ThinkPad-T480s>
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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-06-04 18:29 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-15 19:48 [qemu-upstream-4.11-testing test] 136184: regressions - FAIL osstest service owner
2019-05-15 19:48 ` [Xen-devel] " osstest service owner
2019-05-16 10:37 ` Anthony PERARD
2019-05-16 10:37 ` [Xen-devel] " Anthony PERARD
2019-05-16 21:38 ` Julien Grall
2019-05-16 21:38 ` [Xen-devel] " Julien Grall
2019-05-17 15:53 ` Ian Jackson
2019-05-17 15:53 ` [Xen-devel] " Ian Jackson
2019-05-17 17:23 ` Anthony PERARD
2019-05-17 17:23 ` [Xen-devel] " Anthony PERARD
2019-05-17 19:00 ` Julien Grall
2019-05-17 19:00 ` [Xen-devel] " Julien Grall
2019-05-21 16:52 ` Julien Grall
2019-05-21 16:52 ` [Xen-devel] " Julien Grall
2019-06-03 17:15 ` Anthony PERARD
2019-06-03 17:15 ` [Xen-devel] " Anthony PERARD
2019-06-04 7:06 ` Jan Beulich
2019-06-04 7:06 ` [Xen-devel] " Jan Beulich
2019-06-04 9:01 ` Julien Grall
2019-06-04 9:01 ` [Xen-devel] " Julien Grall
2019-06-04 9:17 ` Jan Beulich
2019-06-04 9:17 ` [Xen-devel] " Jan Beulich
2019-06-04 9:57 ` Julien Grall
2019-06-04 9:57 ` [Xen-devel] " Julien Grall
2019-06-04 10:02 ` Jan Beulich
2019-06-04 10:02 ` [Xen-devel] " Jan Beulich
2019-06-04 17:09 ` Stefano Stabellini
2019-06-04 17:22 ` Julien Grall
2019-06-04 17:39 ` Stefano Stabellini
2019-06-04 17:52 ` Ian Jackson
2019-06-04 18:03 ` Stefano Stabellini
2019-06-04 18:27 ` Ian Jackson [this message]
2019-06-04 18:53 ` Stefano Stabellini
2019-06-04 20:50 ` Julien Grall
2019-06-04 23:11 ` Stefano Stabellini
2019-06-05 10:59 ` Julien Grall
2019-06-05 20:29 ` Stefano Stabellini
2019-06-05 21:38 ` Julien Grall
2019-06-06 8:42 ` Jan Beulich
2019-06-06 8:47 ` Julien Grall
2019-06-06 22:21 ` Stefano Stabellini
2019-06-07 9:33 ` Julien Grall
2019-06-05 10:19 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=23798.47139.259170.371610@mariner.uk.xensource.com \
--to=ian.jackson@citrix.com \
--cc=JBeulich@suse.com \
--cc=anthony.perard@citrix.com \
--cc=julien.grall@arm.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.