Hello,

This series expands the recently introduced Darwin hypervisor build
support to also allow cross-building an x86 hypervisor, that's done in
patches 1 to 3.  Patches 4 and 5 introduce some Cirrus-CI testing to do
cross-builds from macOS, plus it also introduces some basic smoke
testing of the x86 builds using the XTF selftest, just like it's
currently done for the FreeBSD builds.

A result of the updated Cirrus-CI pipeline can be seen at:

https://cirrus-ci.com/build/6723050642604032

Thanks, Roger.

Roger Pau Monne (5):
  xen/x86: always consider '/' as a division in assembly
  xen/tools: remove usages of `stat -c` in check-endbr.sh
  xen/tools: fix grep reporting 'illegal byte sequence' in
    check-endbr.sh
  cirrus-ci: add x86 and arm64 macOS hypervisor builds
  cirrus-ci: add x86 XTF self-tests for macOS build

 .cirrus.yml              | 51 ++++++++++++++++++++++++++++++++++------
 xen/arch/x86/arch.mk     |  5 ++++
 xen/tools/check-endbr.sh | 18 +++++++-------
 3 files changed, 58 insertions(+), 16 deletions(-)

-- 
2.51.0

On 12/02/2026 2:46 pm, Roger Pau Monne wrote:
> Hello,
>
> This series expands the recently introduced Darwin hypervisor build
> support to also allow cross-building an x86 hypervisor, that's done in
> patches 1 to 3.  Patches 4 and 5 introduce some Cirrus-CI testing to do
> cross-builds from macOS, plus it also introduces some basic smoke
> testing of the x86 builds using the XTF selftest, just like it's
> currently done for the FreeBSD builds.
>
> A result of the updated Cirrus-CI pipeline can be seen at:
>
> https://cirrus-ci.com/build/6723050642604032
>
> Thanks, Roger.
>
> Roger Pau Monne (5):
>   xen/x86: always consider '/' as a division in assembly
>   xen/tools: remove usages of `stat -c` in check-endbr.sh
>   xen/tools: fix grep reporting 'illegal byte sequence' in
>     check-endbr.sh
>   cirrus-ci: add x86 and arm64 macOS hypervisor builds
>   cirrus-ci: add x86 XTF self-tests for macOS build

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

The CI tests passing makes this a fairly obvious one to take.

But, some further observations from
https://cirrus-ci.com/task/4903778798796800

[10:09:34.952]   INIT_O  arch/x86/acpi/boot.init.o
[10:09:34.971]   LD      arch/x86/acpi/built_in.o
[10:09:34.975] x86_64-elf-ld: warning: arch/x86/acpi/boot.init.o: missing .note.GNU-stack section implies executable stack
[10:09:34.975] x86_64-elf-ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
...
[10:09:35.720]   LD      arch/x86/boot/built_in.o
[10:09:35.724]   CC      common/hypfs.o
[10:09:35.727] x86_64-elf-ld: warning: arch/x86/boot/reloc-trampoline.o: missing .note.GNU-stack section implies executable stack
[10:09:35.727] x86_64-elf-ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
...
[10:09:40.836]   LD      arch/x86/hvm/svm/built_in.o
[10:09:40.840] x86_64-elf-ld: warning: arch/x86/hvm/svm/vmcb.o: missing .note.GNU-stack section implies executable stack
[10:09:40.840] x86_64-elf-ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker


and various other examples too.  The warning comes when linking
built_in.o's, and while I could believe there's something weird about
*.init.o and/or reloc-trampoline.o, the complaint about vmcb.o is weird
because that's just a plain C file.

The other impacted (non built_in.o) objects look to be:

arch/x86/hvm/vmx/vvmx.o
arch/x86/pv/dom0_build.init.o
arch/x86/x86_64/cpufreq.o
common/unzstd.init.o

and it's not obvious what these have in common to be the (only) objects
lacking .note.GNU-stack.


Also, during the final link steps for xen.efi, we twice get:

[10:09:57.995] Warning: relocation to r/o section .text:00000048
[10:09:57.995] Warning: relocation to r/o section .text:00000090

which smells like the multiboot header.

~Andrew

On 12.02.2026 18:58, Andrew Cooper wrote:
> Also, during the final link steps for xen.efi, we twice get:
> 
> [10:09:57.995] Warning: relocation to r/o section .text:00000048
> [10:09:57.995] Warning: relocation to r/o section .text:00000090
> 
> which smells like the multiboot header.

It is. These diagnostics are seen only when older ld is in use, but the
issue exists in all cases. It should really already be on someone's todo
list wrt fully secure boot conformant xen.efi, as we did discuss this in
the past.

Jan

On Fri, Feb 13, 2026 at 09:22:24AM +0100, Jan Beulich wrote:
> On 12.02.2026 18:58, Andrew Cooper wrote:
> > Also, during the final link steps for xen.efi, we twice get:
> > 
> > [10:09:57.995] Warning: relocation to r/o section .text:00000048
> > [10:09:57.995] Warning: relocation to r/o section .text:00000090
> > 
> > which smells like the multiboot header.
> 
> It is. These diagnostics are seen only when older ld is in use, but the
> issue exists in all cases.

Oh, it took me a while to figure that out.  Newer ld generates the
relocations itself, and hence we no longer use mkreloc that would
print those warnings.  However ld generated relocations will still be
against read-execute section, and hence as you say the issue also
exists there.

However the ld version on Darwin is:

GNU ld (GNU Binutils) 2.45.1

So the issue is not with the version of ld using in the Darwin build
being too old, but rather the checking done in efi-nr-fixups not
working well with BSD grep.  It needs to be adjusted to use -E,
otherwise [[:blank:]] is not recognized.  I will send a patch.

> It should really already be on someone's todo
> list wrt fully secure boot conformant xen.efi, as we did discuss this in
> the past.

I did start on it:

https://lore.kernel.org/xen-devel/20250401130840.72119-1-roger.pau@citrix.com/

However at the time I did this, the XenServer Secure Boot
implementation was doing something that would have been incompatible
with this work, and hence I set it on the side.  Later on, the
XenServer implementation changed and picked up most of this work
internally.  I however never got back to this work, neither the people
that internally worked on Secure Boot send an updated version of the
patches.

I will see whether I can make some progress on this.

Thanks, Roger.