[Bug]: Build TFA and Hafnium in Windows is broken

[kuqin12]

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

If we set the HAF_TFA_BUILD flag to true in Windows build, it is broken: https://github.com/OpenDevicePartnership/patina-qemu/actions/runs/23889405181/job/69659110665#step:7:6026

Expected Behavior

Either we build it in wsl, or fix the build break.

Steps To Reproduce

https://github.com/OpenDevicePartnership/patina-qemu/actions/runs/23889405181/job/69659110665#step:7:6026

Build Environment

- OS(s): Windows
- Targets Impacted: AArch64

Version Information

Top of main

Urgency

Medium

Are you going to fix this?

Someone else needs to fix it

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response

[os-d]

@kuqin12 this is expected and documented:

patina-qemu/Platforms/Docs/Common/building.md

Line 33 in bfc657f

>**Note:**: By default, Hafnium and TF-A (only used in the QemuSbsaPkg build) are pulled in as precompiled binaries.

. We know that TF-A doesn’t support building natively on Windows.

[makubacki]

Closing as not planned.

[kuqin12]

But how do you update the binary and pass pipeline build if they need to be updated? This issue should remain open until there is a solution for that.

[os-d]

Had an offline conversation to understand the scenario better. The issue is really for both Linux and Windows CI, that when TF-A or Hafnium is updated, CI will be broken if the corresponding UEFI changes are made at the same time, because the ext dep pulls from the patina-qemu release, which can't be made until the TF-A and Hafnium changes are checked in and a release is made.

To work around this in the past, folks have changed the CI files to build TF-A and Hafnium from source instead of pulling the ext dep, make a release, then put it back.

My recommendation for now is to check in the TF-A and Hafnium updates without the UEFI changes, make a release, then do a follow up PR to make the UEFI changes and update the ext dep to the new release.

Longer term we have discussed moving TF-A and Hafnium out to their own repos, in which case this is not a problem because the ext dep pulls from an external release.

Another option is to go to the TF-A and Hafnium upstreams and enable Windows CI. The projects would need to agree to this, but have been amenable in the past.

[makubacki]

check in the TF-A and Hafnium updates without the UEFI changes, make a release, then do a follow up PR to make the UEFI changes and update the ext dep to the new release.

I thought this order of operations would be required as opposed to optional with the way this is currently setup.

---

How much work is the below item?

Another option is to go to the TF-A and Hafnium upstreams and enable Windows CI.

Given this is a relatively common use case for us, even more so after CLANGPDB brought compilation back on Windows, it would be nice to have.

[kuqin12]

If the precompiled binary is stale, we will need an updated binary to pair with the UEFI change to pass pipeline validation. It used to work because we only verify SBSA in ubuntu, and source build works. So how it used to work is that

1. we enforce the build flag to be true to pass the build
2. make a release with the updated mainline
3. file a subsequent PR that disables the build flag with updated binary

I think 4 options on this:

1. Fix Hafnium and TFA build in Windows for now.
2. Thunk their build into wsl when building on Windows.
3. Add a flag for the Windows build pipeline to consume the binary from build-haf-tfa.yml when needed.
4. Separate the build of TFA and Hafnium into their own pipeline. The catch is that TFA carries some manifest that needs to match its secure partitions...

Adding @eeshanl as he is looking at this right now.