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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan