Re: [xen-4.13-testing bisection] complete build-amd64

[Ian Jackson <iwj@xxxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [xen-4.13-testing bisection] complete build-amd64"):
> On 09.09.2021 11:52, osstest service owner wrote:
> >   commit 9f3eda177a4b2d4a33ff1b0307cad42906396562
> >   Author: Lin, Gary (HPS OE-Linux) <gary.lin@xxxxxxx>
> >   Date:   Tue Aug 31 09:29:48 2021 +0800
> >   
> >       OvmfPkg/OvmfXen: add QemuKernelLoaderFsDxe
> >       
> >       Without QemuKernelLoaderFsDxe, QemuLoadKernelImage() couldn't download
> >       the kernel, initrd, and kernel command line from QEMU's fw_cfg.
> >       
> >       Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3574
> >       Signed-off-by: Gary Lin <gary.lin@xxxxxxx>
> >       Acked-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
> >       Reviewed-by: Philippe Mathieu-Daude <philmd@xxxxxxxxxx>
> >       Reviewed-by: Gerd Hoffmann <kraxel@xxxxxxxxxx>
> >       Tested-by: Jim Fehlig <jfehlig@xxxxxxxx>
> 
> I'm really curious as to how this could have been identified as the
> culprit, when the build issue was a plain hypervisor side one (which
> Andrew did supply a fix for yesterday).

It's a bisector.  It doesn't look at error messages.  So it can't tell
whether a build failure is "the same" as another build failure.

What it starts out knowing is this:


  --good---------------------------------------------------------bad
   (long ago)                                                   [gfn_t]

It picks some random spot ~halfway[1]

  --good-------------------------bad-----------------------------bad
   (long ago)                   [ovmf]                          [gfn_t]

And then of course it's bisecting the ovmf build failure.

Or to put it another way, the build has been broken since the ovmf
change broke it.

[1] It has actually identified the change in the ovmf tree.  For the
purposes of bisection it bisects over a constructed graph whose nodes
are tuples of versions of all the relevant tree.

Ian.