[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH for-4.13] clang: do not enable live-patching support
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: Lars Kurth <lars.kurth.xen@xxxxxxxxx>
- Date: Fri, 6 Dec 2019 14:58:38 -0600
- Cc: Jürgen Groß <jgross@xxxxxxxx>, Lars Kurth <lars.kurth@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>, 'Jan Beulich' <jbeulich@xxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>
- Delivery-date: Fri, 06 Dec 2019 20:59:07 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 03/12/2019 09:17, George Dunlap wrote:
On Dec 2, 2019, at 5:01 PM, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
On Mon, Dec 02, 2019 at 03:55:04PM +0000, Andrew Cooper wrote:
On 02/12/2019 15:53, Konrad Rzeszutek Wilk wrote:
I plan to release ack the patch in case the missing maintainer's acks are not coming in too late.
I think Andy's objection was that there has been zero testing of livepatching on gcc. Maybe we can find someone to do a smoke-test.
As in integrate livepatch-build tools in osstest smoke-tests? Because the livepatch test cases are in osstest, unless something went awry?
The sum total of livepatch testing in OSSTest is using the hand-coded ELF objects from the tests/ directory.
This is perhaps ok for the basic mechanism, but its not representative of actually building real livepatches using livepatch build tools.
True. But it tests the _hypervisor_ livepatch code.
I am thinking that this discussion about "oh, but livepatch-build tools don't work b/c" is well <shrug> sucks but should never block an release as the core livepatch functionality is OK.
I think a parallel is if Xen doesn’t build with a particular version of the compiler, or can’t build on a particular distro for some reason. We should certainly *try* to make things work with other projects, but if the issue is clearly with the other project, we shouldn’t have to block to wait for that other project to get things sorted out.
This isn't a valid comparison.livepatch-build-tools is a concrete thing, built and maintained by us(the Xen community), explicitly for the purpose generating livepatchesbetween two versions of Xen. It lives athttps://xenbits.xen.org/gitweb/?p=livepatch-build-tools.git;a=summary onxenbits, just like xen.git.
First a couple of questions: I noticed that neither Ross to xen-devel is on this thread
I agree with Andy: we got away lucky so far, as there have been few changes to the live patch-build-tools
It *should* be used in OSSTest, have a push gate, and block breaking changes either to Xen or to the tools themselves, before the breaking changes get accepted into master of either repo.
Although I agree with you, we should not block 4.13 for it and do some manual testing for this release But we should have a plan in place for 4.14 to address this and maybe agree to block 4.14 if that has not happened
Lars |
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|