Re: [xen-4.12-testing bisection] complete test-amd64-i386-xl-qemuu-ovmf-amd64

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Mon, Aug 23, 2021 at 12:07:44PM +0200, Jan Beulich wrote:
> On 23.08.2021 11:33, Anthony PERARD wrote:
> > On Mon, Aug 23, 2021 at 09:07:32AM +0200, Jan Beulich wrote:
> >> On 23.08.2021 02:40, osstest service owner wrote:
> >>>   commit d06eb2d1d9dd8da1ed84bd08c5783a0264fe2b64
> >>>   Author: Laszlo Ersek <lersek@xxxxxxxxxx>
> >>>   Date:   Wed May 26 22:14:24 2021 +0200
> >>>   
> >>>       OvmfPkg/PlatformPei: remove Xen support
> >>
> >> Uniformly from 4.15 through to 4.12 (the latter of which shouldn't have
> >> been affected by whatever has been pulled in in the first place, given
> >> it's a security-only branch, but with the OVMF commit to use being
> >> hardcoded in ./Config.mk I don't really understand how a possible
> >> change to the OVMF tree could have affected this version) tests are
> >> now failing, everywhere with the above bisection result. Given that we
> >> want to get out releases from the 4.15 and 4.13 branches right after
> >> the batch of XSAs going public on Wednesday, something needs to be
> >> done about this pretty soon.
> >>
> >> Does osstest override ./Config.mk's choice? Albeit I guess even if it
> >> does that's not outright wrong, and instead it would be bad if the
> >> older versions wouldn't work anymore with an updated OVMF.
> > 
> > Yes, osstest uses "xen-tested-master" branch since c9d1e5896fe2
> > ("cr-daily-branch: ovmf: "usually" use xen-tested-master") for stable
> > branches.
> > 
> > We are going to need to backport a commit from unstable. Either
> >     aad7b5c11d51 ("tools/firmware/ovmf: Use OvmfXen platform file is exist")
> >         (but has been reverted)
> > or
> >     81f291420238 ("tools/firmware/ovmf: Use OvmfXen platform file if exist 
> > and update OVMF")
> >         (but it also changes the version of ovmf pulled by default,
> >          which we probably don't want to change)
> > 
> > So I would suggest backporting aad7b5c11d51.
> 
> Anthony - thanks for the quick reply.
> 
> Ian - that's largely your call then I guess.
> 
> Overall I'm not convinced though that backporting either of these
> changes is the way to go. But I say this without knowing what the
> background is for osstest's overriding of Config.mk. Plus it's not
> immediately clear to me whether backporting is perhaps the only
> approach to keeping older Xen versions working with up-to-date
> OVMF; I'm getting the impression that it might be.

Well, a better approach would be for osstest to do a separate build for
OVMF, but in the meantime we are stuck with xen.git having to build
everything.

-- 
Anthony PERARD