| Message ID | 1453116164.6020.118.camel@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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@eu.citrix.com>
> #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@cardoe.com> today at the latest.
FR, this latter message is "tools: make FLASK utils build
unconditional".
With these, is osstest going to DTRT ?
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.
Ian.
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@eu.citrix.com> 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@cardoe.com> 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.
On Mon, 2016-01-18 at 11:36 +0000, Ian Campbell wrote: > 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@eu.citrix.com> > > 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@cardoe.com> 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. > [...] > So I think we can go ahead and I will turn the above into an osstest > patch in parallel. Ian was convinced by my argumentation here (and told me so on IRC) so I have gone ahead and pushed this and acked + applied Doug's patch too. Ian.
diff --git a/xen/Makefile b/xen/Makefile index 3699b20..2b34898 100644 --- a/xen/Makefile +++ b/xen/Makefile @@ -58,7 +58,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX) ln -f -s $(T)-$(XEN_FULLVERSION)$(Z) $(D)$(BOOT_DIR)/$(T)$(Z) [ -d "$(D)$(DEBUG_DIR)" ] || $(INSTALL_DIR) $(D)$(DEBUG_DIR) $(INSTALL_DATA) $(TARGET)-syms $(D)$(DEBUG_DIR)/$(T)-syms-$(XEN_FULLVERSION) - $(INSTALL_DATA) $(KCONFIG_CONFIG) $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).config + $(INSTALL_DATA) $(KCONFIG_CONFIG) $(D)$(BOOT_DIR)/$(T)-$(XEN_FULLVERSION).config if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \ [ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \ $(INSTALL_DATA) $(TARGET).efi $(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \