Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]

[Ian Campbell <ian.campbell@citrix.com>]

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel