[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
On Mon, 2016-01-18 at 11:28 +0000, Ian Jackson wrote: > Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 77945: > regressions - FAIL [and 2 more messages]"): > > On Mon, 2016-01-18 at 02:47 -0700, Jan Beulich wrote: > > > Ugly. Could we live with that until #1 and #2 get put in place? > > > > #1 is trivial (see below). > > Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Thanks. > > #2 is, as noted in my original mail, something which while it logically > > belongs between #1 and #3 could be deferred. > > > > > Otherwise it looks very much like reverting the two Kconfig > > > conversion patches is the only possible solution at this point... > > > > IMHO we should apply the patch below + Doug's patch from <1452879580- > > 1770-1 > > -git-send-email-cardoe@xxxxxxxxxx> todayÂat the latest. > > FR, this latter message is "tools: make FLASK utils build > unconditional". > > With these, is osstest going to DTRT ? I think so. > My fear is that the appearance of the policy will cause non-XSM builds > to generate an XSM boot entry which will osstest might select.ÂÂBut I > haven't peered at the interlocking bits of code to see what will > happen. Osstest::Debian::setupboot_grub2 takes a "$want_xsm" parameter and has code: Â Â Â Â Â Â Â Â } elsif ($want_xsm && !defined $entry->{Xenpolicy}) { ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂlogm("(skipping entry at $entry->{StartLine}..$.;". ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ" XSM policy file not present)"); which isn't quite what I expected, as it solves half the problem (booting a non-XSM Xen when Xsm is desired) I think. I think we'd want to add another case like: Â Â Â Â Â Â Â Â } elsif (!$want_xsm && defined $entry->{Xenpolicy}) { ÂÂÂÂÂÂ ÂÂÂÂÂÂÂÂÂÂÂÂÂÂlogm("(skipping entry at $entry->{StartLine}..$.;". ÂÂÂÂÂÂÂÂÂÂ ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ" XSM policy file present)"); ? However I don't think this is urgent (i.e. blocking) since, as it happens (and due to the way 20_linux_xen is patched), the non-XSM entry always precedes the XSM one, so a non-XSM test would find that first and stop looking. So I think we can go ahead and I will turn the above into an osstest patch in parallel. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |