Xen does not provide a Darwin build configuration for selecting
GNU tool definitions. On macOS, the tools we use are either GNU
compatible or we only rely on features supported by Mac OS, so
using the GNU tool definitions is appropriate.

Add config/Darwin.mk to include StdGNU.mk and force
XEN_COMPILE_ARCH=Darwin, ensuring Darwin builds always follow
the cross-compile path as we depend on the Linux ABI so compiling
on Mac OS is always a cross compilation case.

An example of how to build the hypervisor for arm64 on Mac OS
(tools cannot be build for now) using a compiler from brew:
- brew install aarch64-elf-gcc
- cd xen
- make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=gcc

Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
---
Changes since v2:
- Subject was "xen: Add macOS hypervisor build configuration"
- Update Darwin.mk comments to more accurate versions (Jan)
- Remove the build-on-macos help as we have no dependency on anything
  coming from brew anymore and the toolchain can be retrieved by lots of
  other solutions than brew on mac os. Switch to a simple doc in the
  commit message instead
---
 config/Darwin.mk | 7 +++++++
 1 file changed, 7 insertions(+)
 create mode 100644 config/Darwin.mk

diff --git a/config/Darwin.mk b/config/Darwin.mk
new file mode 100644
index 000000000000..427588eaf899
--- /dev/null
+++ b/config/Darwin.mk
@@ -0,0 +1,7 @@
+# Use GNU tool definitions as the tools we are using are either GNU compatible
+# or we only use features which are supported on Mac OS.
+include $(XEN_ROOT)/config/StdGNU.mk
+
+# Xen uses Linux'es ABI so we are cross compiling on Mac OS.
+# Force COMPILE_ARCH to a fake value to make sure it is always the case.
+XEN_COMPILE_ARCH = Darwin
-- 
2.52.0

On 06.02.2026 09:17, Bertrand Marquis wrote:
> Xen does not provide a Darwin build configuration for selecting
> GNU tool definitions. On macOS, the tools we use are either GNU
> compatible or we only rely on features supported by Mac OS, so
> using the GNU tool definitions is appropriate.
> 
> Add config/Darwin.mk to include StdGNU.mk and force
> XEN_COMPILE_ARCH=Darwin, ensuring Darwin builds always follow
> the cross-compile path as we depend on the Linux ABI so compiling
> on Mac OS is always a cross compilation case.
> 
> An example of how to build the hypervisor for arm64 on Mac OS
> (tools cannot be build for now) using a compiler from brew:
> - brew install aarch64-elf-gcc
> - cd xen
> - make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=gcc
> 
> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
> ---
> Changes since v2:
> - Subject was "xen: Add macOS hypervisor build configuration"
> - Update Darwin.mk comments to more accurate versions (Jan)
> - Remove the build-on-macos help as we have no dependency on anything
>   coming from brew anymore and the toolchain can be retrieved by lots of
>   other solutions than brew on mac os. Switch to a simple doc in the
>   commit message instead

Did you see Roger's notice on Matrix about objcopy?

> --- /dev/null
> +++ b/config/Darwin.mk
> @@ -0,0 +1,7 @@
> +# Use GNU tool definitions as the tools we are using are either GNU compatible
> +# or we only use features which are supported on Mac OS.
> +include $(XEN_ROOT)/config/StdGNU.mk
> +
> +# Xen uses Linux'es ABI so we are cross compiling on Mac OS.
> +# Force COMPILE_ARCH to a fake value to make sure it is always the case.
> +XEN_COMPILE_ARCH = Darwin

I first wondered why you say "fake", seeing the file is named Darwin.mk. But
in Config.mk's cross-compile check the build host OS doesn't even matter. So
yes, it needs faking here for the time being.

Jan

On Fri, Feb 06, 2026 at 11:38:02AM +0100, Jan Beulich wrote:
> On 06.02.2026 09:17, Bertrand Marquis wrote:
> > Xen does not provide a Darwin build configuration for selecting
> > GNU tool definitions. On macOS, the tools we use are either GNU
> > compatible or we only rely on features supported by Mac OS, so
> > using the GNU tool definitions is appropriate.
> > 
> > Add config/Darwin.mk to include StdGNU.mk and force
> > XEN_COMPILE_ARCH=Darwin, ensuring Darwin builds always follow
> > the cross-compile path as we depend on the Linux ABI so compiling
> > on Mac OS is always a cross compilation case.
> > 
> > An example of how to build the hypervisor for arm64 on Mac OS
> > (tools cannot be build for now) using a compiler from brew:
> > - brew install aarch64-elf-gcc
> > - cd xen
> > - make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=gcc
> > 
> > Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
> > ---
> > Changes since v2:
> > - Subject was "xen: Add macOS hypervisor build configuration"
> > - Update Darwin.mk comments to more accurate versions (Jan)
> > - Remove the build-on-macos help as we have no dependency on anything
> >   coming from brew anymore and the toolchain can be retrieved by lots of
> >   other solutions than brew on mac os. Switch to a simple doc in the
> >   commit message instead
> 
> Did you see Roger's notice on Matrix about objcopy?

I think Bertrand considers objcopy to be part of the toolchain, hence
"retrieving a toolchain" is meant to include objcopy (either the GNU,
LLVM or elftoolchain one)

> > --- /dev/null
> > +++ b/config/Darwin.mk
> > @@ -0,0 +1,7 @@
> > +# Use GNU tool definitions as the tools we are using are either GNU compatible
> > +# or we only use features which are supported on Mac OS.
> > +include $(XEN_ROOT)/config/StdGNU.mk
> > +
> > +# Xen uses Linux'es ABI so we are cross compiling on Mac OS.
> > +# Force COMPILE_ARCH to a fake value to make sure it is always the case.
> > +XEN_COMPILE_ARCH = Darwin
> 
> I first wondered why you say "fake", seeing the file is named Darwin.mk. But
> in Config.mk's cross-compile check the build host OS doesn't even matter. So
> yes, it needs faking here for the time being.

Hm, setting it to "Darwin" seems weird to me.  I understand the
purpose of this is to force the user to set XEN_TARGET_ARCH
explicitly.  I however wouldn't see it as fully uncorrect to not set
this.  It will then execute `uname -m` and get `arm64` back for Apple
silicon macs (which is kind of OK?).  Other I suggest we use a non-OSX
specific value here, so that if required we could distinguish this
case where the user is expected to provide XEN_COMPILE_ARCH.

Maybe XEN_COMPILE_ARCH = { unknown | undefined }?

Thanks, Roger.

> On 6 Feb 2026, at 14:29, Roger Pau Monné <roger.pau@citrix.com> wrote:
> 
> On Fri, Feb 06, 2026 at 11:38:02AM +0100, Jan Beulich wrote:
>> On 06.02.2026 09:17, Bertrand Marquis wrote:
>>> Xen does not provide a Darwin build configuration for selecting
>>> GNU tool definitions. On macOS, the tools we use are either GNU
>>> compatible or we only rely on features supported by Mac OS, so
>>> using the GNU tool definitions is appropriate.
>>> 
>>> Add config/Darwin.mk to include StdGNU.mk and force
>>> XEN_COMPILE_ARCH=Darwin, ensuring Darwin builds always follow
>>> the cross-compile path as we depend on the Linux ABI so compiling
>>> on Mac OS is always a cross compilation case.
>>> 
>>> An example of how to build the hypervisor for arm64 on Mac OS
>>> (tools cannot be build for now) using a compiler from brew:
>>> - brew install aarch64-elf-gcc
>>> - cd xen
>>> - make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=gcc
>>> 
>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>> ---
>>> Changes since v2:
>>> - Subject was "xen: Add macOS hypervisor build configuration"
>>> - Update Darwin.mk comments to more accurate versions (Jan)
>>> - Remove the build-on-macos help as we have no dependency on anything
>>>  coming from brew anymore and the toolchain can be retrieved by lots of
>>>  other solutions than brew on mac os. Switch to a simple doc in the
>>>  commit message instead
>> 
>> Did you see Roger's notice on Matrix about objcopy?
> 
> I think Bertrand considers objcopy to be part of the toolchain, hence
> "retrieving a toolchain" is meant to include objcopy (either the GNU,
> LLVM or elftoolchain one)

Sorry i only saw your message in matrix.

I checked and i installed both gcc and binutils in homebrew.

So i think the commit message needs modifying to stay:

brew install aarch64-elf-gcc aarch64-elf-binutils

to be fully complete.

> 
>>> --- /dev/null
>>> +++ b/config/Darwin.mk
>>> @@ -0,0 +1,7 @@
>>> +# Use GNU tool definitions as the tools we are using are either GNU compatible
>>> +# or we only use features which are supported on Mac OS.
>>> +include $(XEN_ROOT)/config/StdGNU.mk
>>> +
>>> +# Xen uses Linux'es ABI so we are cross compiling on Mac OS.
>>> +# Force COMPILE_ARCH to a fake value to make sure it is always the case.
>>> +XEN_COMPILE_ARCH = Darwin
>> 
>> I first wondered why you say "fake", seeing the file is named Darwin.mk. But
>> in Config.mk's cross-compile check the build host OS doesn't even matter. So
>> yes, it needs faking here for the time being.
> 
> Hm, setting it to "Darwin" seems weird to me.  I understand the
> purpose of this is to force the user to set XEN_TARGET_ARCH
> explicitly.  I however wouldn't see it as fully uncorrect to not set
> this.  It will then execute `uname -m` and get `arm64` back for Apple
> silicon macs (which is kind of OK?).  Other I suggest we use a non-OSX
> specific value here, so that if required we could distinguish this
> case where the user is expected to provide XEN_COMPILE_ARCH.
> 
> Maybe XEN_COMPILE_ARCH = { unknown | undefined }?

I am ok to change this with either but maybe unsupported could be
a third choice?

Cheers
Bertrand

> 
> Thanks, Roger.

On 06.02.2026 14:34, Bertrand Marquis wrote:
>> On 6 Feb 2026, at 14:29, Roger Pau Monné <roger.pau@citrix.com> wrote:
>> On Fri, Feb 06, 2026 at 11:38:02AM +0100, Jan Beulich wrote:
>>> On 06.02.2026 09:17, Bertrand Marquis wrote:
>>>> --- /dev/null
>>>> +++ b/config/Darwin.mk
>>>> @@ -0,0 +1,7 @@
>>>> +# Use GNU tool definitions as the tools we are using are either GNU compatible
>>>> +# or we only use features which are supported on Mac OS.
>>>> +include $(XEN_ROOT)/config/StdGNU.mk
>>>> +
>>>> +# Xen uses Linux'es ABI so we are cross compiling on Mac OS.
>>>> +# Force COMPILE_ARCH to a fake value to make sure it is always the case.
>>>> +XEN_COMPILE_ARCH = Darwin
>>>
>>> I first wondered why you say "fake", seeing the file is named Darwin.mk. But
>>> in Config.mk's cross-compile check the build host OS doesn't even matter. So
>>> yes, it needs faking here for the time being.
>>
>> Hm, setting it to "Darwin" seems weird to me.  I understand the
>> purpose of this is to force the user to set XEN_TARGET_ARCH
>> explicitly.  I however wouldn't see it as fully uncorrect to not set
>> this.  It will then execute `uname -m` and get `arm64` back for Apple
>> silicon macs (which is kind of OK?).  Other I suggest we use a non-OSX
>> specific value here, so that if required we could distinguish this
>> case where the user is expected to provide XEN_COMPILE_ARCH.
>>
>> Maybe XEN_COMPILE_ARCH = { unknown | undefined }?
> 
> I am ok to change this with either but maybe unsupported could be
> a third choice?

If I ran into "unsupported" there, I'd wonder if I even should trust any of
this and try it out. I'd prefer either of Roger's suggestions, in the order
given.

Jan

Hi Jan,

> On 6 Feb 2026, at 16:00, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 06.02.2026 14:34, Bertrand Marquis wrote:
>>> On 6 Feb 2026, at 14:29, Roger Pau Monné <roger.pau@citrix.com> wrote:
>>> On Fri, Feb 06, 2026 at 11:38:02AM +0100, Jan Beulich wrote:
>>>> On 06.02.2026 09:17, Bertrand Marquis wrote:
>>>>> --- /dev/null
>>>>> +++ b/config/Darwin.mk
>>>>> @@ -0,0 +1,7 @@
>>>>> +# Use GNU tool definitions as the tools we are using are either GNU compatible
>>>>> +# or we only use features which are supported on Mac OS.
>>>>> +include $(XEN_ROOT)/config/StdGNU.mk
>>>>> +
>>>>> +# Xen uses Linux'es ABI so we are cross compiling on Mac OS.
>>>>> +# Force COMPILE_ARCH to a fake value to make sure it is always the case.
>>>>> +XEN_COMPILE_ARCH = Darwin
>>>> 
>>>> I first wondered why you say "fake", seeing the file is named Darwin.mk. But
>>>> in Config.mk's cross-compile check the build host OS doesn't even matter. So
>>>> yes, it needs faking here for the time being.
>>> 
>>> Hm, setting it to "Darwin" seems weird to me.  I understand the
>>> purpose of this is to force the user to set XEN_TARGET_ARCH
>>> explicitly.  I however wouldn't see it as fully uncorrect to not set
>>> this.  It will then execute `uname -m` and get `arm64` back for Apple
>>> silicon macs (which is kind of OK?).  Other I suggest we use a non-OSX
>>> specific value here, so that if required we could distinguish this
>>> case where the user is expected to provide XEN_COMPILE_ARCH.
>>> 
>>> Maybe XEN_COMPILE_ARCH = { unknown | undefined }?
>> 
>> I am ok to change this with either but maybe unsupported could be
>> a third choice?
> 
> If I ran into "unsupported" there, I'd wonder if I even should trust any of
> this and try it out. I'd prefer either of Roger's suggestions, in the order
> given.

unknown it is.
works for me

Cheers
Bertrand

> 
> Jan

On Fri, Feb 06, 2026 at 01:34:23PM +0000, Bertrand Marquis wrote:
> 
> 
> > On 6 Feb 2026, at 14:29, Roger Pau Monné <roger.pau@citrix.com> wrote:
> > 
> > On Fri, Feb 06, 2026 at 11:38:02AM +0100, Jan Beulich wrote:
> >> On 06.02.2026 09:17, Bertrand Marquis wrote:
> >>> Xen does not provide a Darwin build configuration for selecting
> >>> GNU tool definitions. On macOS, the tools we use are either GNU
> >>> compatible or we only rely on features supported by Mac OS, so
> >>> using the GNU tool definitions is appropriate.
> >>> 
> >>> Add config/Darwin.mk to include StdGNU.mk and force
> >>> XEN_COMPILE_ARCH=Darwin, ensuring Darwin builds always follow
> >>> the cross-compile path as we depend on the Linux ABI so compiling
> >>> on Mac OS is always a cross compilation case.
> >>> 
> >>> An example of how to build the hypervisor for arm64 on Mac OS
> >>> (tools cannot be build for now) using a compiler from brew:
> >>> - brew install aarch64-elf-gcc
> >>> - cd xen
> >>> - make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=gcc

I've just noticed: it's a bit misleading to use HOSTCC=gcc here, as
(under a normal OSX system) gcc is a plain wrapped around clang:

% gcc -v
Apple clang version 17.0.0 (clang-1700.6.3.2)
Target: arm64-apple-darwin24.6.0
Thread model: posix

You might as well use HOSTCC=clang and make it explicit the host
compiler is clang and not gcc.

> >>> 
> >>> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
> >>> ---
> >>> Changes since v2:
> >>> - Subject was "xen: Add macOS hypervisor build configuration"
> >>> - Update Darwin.mk comments to more accurate versions (Jan)
> >>> - Remove the build-on-macos help as we have no dependency on anything
> >>>  coming from brew anymore and the toolchain can be retrieved by lots of
> >>>  other solutions than brew on mac os. Switch to a simple doc in the
> >>>  commit message instead
> >> 
> >> Did you see Roger's notice on Matrix about objcopy?
> > 
> > I think Bertrand considers objcopy to be part of the toolchain, hence
> > "retrieving a toolchain" is meant to include objcopy (either the GNU,
> > LLVM or elftoolchain one)
> 
> Sorry i only saw your message in matrix.
> 
> I checked and i installed both gcc and binutils in homebrew.
> 
> So i think the commit message needs modifying to stay:
> 
> brew install aarch64-elf-gcc aarch64-elf-binutils
> 
> to be fully complete.

Yes, I didn't notice that in the commit message you explicitly
mentioned the brew install dependencies.  There's also bison and flex
needed for Kconfig, but AFAICT those are part of command line tools.
I think python is also part of the command line tools, and not sure
it's required for arm64, as it's required for x86 to generate the
cpuid headers (but I don't know if arm64 has anything equivalent).

> > 
> >>> --- /dev/null
> >>> +++ b/config/Darwin.mk
> >>> @@ -0,0 +1,7 @@
> >>> +# Use GNU tool definitions as the tools we are using are either GNU compatible
> >>> +# or we only use features which are supported on Mac OS.
> >>> +include $(XEN_ROOT)/config/StdGNU.mk
> >>> +
> >>> +# Xen uses Linux'es ABI so we are cross compiling on Mac OS.
> >>> +# Force COMPILE_ARCH to a fake value to make sure it is always the case.
> >>> +XEN_COMPILE_ARCH = Darwin
> >> 
> >> I first wondered why you say "fake", seeing the file is named Darwin.mk. But
> >> in Config.mk's cross-compile check the build host OS doesn't even matter. So
> >> yes, it needs faking here for the time being.
> > 
> > Hm, setting it to "Darwin" seems weird to me.  I understand the
> > purpose of this is to force the user to set XEN_TARGET_ARCH
> > explicitly.  I however wouldn't see it as fully uncorrect to not set
> > this.  It will then execute `uname -m` and get `arm64` back for Apple
> > silicon macs (which is kind of OK?).  Other I suggest we use a non-OSX
> > specific value here, so that if required we could distinguish this
> > case where the user is expected to provide XEN_COMPILE_ARCH.
> > 
> > Maybe XEN_COMPILE_ARCH = { unknown | undefined }?
> 
> I am ok to change this with either but maybe unsupported could be
> a third choice?

No strong opinion for either naming, as long as we don't explicitly
use "Darwin".

Thanks, Roger.

Hi Roger,

> On 6 Feb 2026, at 15:16, Roger Pau Monné <roger.pau@citrix.com> wrote:
> 
> On Fri, Feb 06, 2026 at 01:34:23PM +0000, Bertrand Marquis wrote:
>> 
>> 
>>> On 6 Feb 2026, at 14:29, Roger Pau Monné <roger.pau@citrix.com> wrote:
>>> 
>>> On Fri, Feb 06, 2026 at 11:38:02AM +0100, Jan Beulich wrote:
>>>> On 06.02.2026 09:17, Bertrand Marquis wrote:
>>>>> Xen does not provide a Darwin build configuration for selecting
>>>>> GNU tool definitions. On macOS, the tools we use are either GNU
>>>>> compatible or we only rely on features supported by Mac OS, so
>>>>> using the GNU tool definitions is appropriate.
>>>>> 
>>>>> Add config/Darwin.mk to include StdGNU.mk and force
>>>>> XEN_COMPILE_ARCH=Darwin, ensuring Darwin builds always follow
>>>>> the cross-compile path as we depend on the Linux ABI so compiling
>>>>> on Mac OS is always a cross compilation case.
>>>>> 
>>>>> An example of how to build the hypervisor for arm64 on Mac OS
>>>>> (tools cannot be build for now) using a compiler from brew:
>>>>> - brew install aarch64-elf-gcc
>>>>> - cd xen
>>>>> - make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=gcc
> 
> I've just noticed: it's a bit misleading to use HOSTCC=gcc here, as
> (under a normal OSX system) gcc is a plain wrapped around clang:
> 
> % gcc -v
> Apple clang version 17.0.0 (clang-1700.6.3.2)
> Target: arm64-apple-darwin24.6.0
> Thread model: posix
> 
> You might as well use HOSTCC=clang and make it explicit the host
> compiler is clang and not gcc.

true

> 
>>>>> 
>>>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>>>> ---
>>>>> Changes since v2:
>>>>> - Subject was "xen: Add macOS hypervisor build configuration"
>>>>> - Update Darwin.mk comments to more accurate versions (Jan)
>>>>> - Remove the build-on-macos help as we have no dependency on anything
>>>>> coming from brew anymore and the toolchain can be retrieved by lots of
>>>>> other solutions than brew on mac os. Switch to a simple doc in the
>>>>> commit message instead
>>>> 
>>>> Did you see Roger's notice on Matrix about objcopy?
>>> 
>>> I think Bertrand considers objcopy to be part of the toolchain, hence
>>> "retrieving a toolchain" is meant to include objcopy (either the GNU,
>>> LLVM or elftoolchain one)
>> 
>> Sorry i only saw your message in matrix.
>> 
>> I checked and i installed both gcc and binutils in homebrew.
>> 
>> So i think the commit message needs modifying to stay:
>> 
>> brew install aarch64-elf-gcc aarch64-elf-binutils
>> 
>> to be fully complete.
> 
> Yes, I didn't notice that in the commit message you explicitly
> mentioned the brew install dependencies.  There's also bison and flex
> needed for Kconfig, but AFAICT those are part of command line tools.
> I think python is also part of the command line tools, and not sure
> it's required for arm64, as it's required for x86 to generate the
> cpuid headers (but I don't know if arm64 has anything equivalent).

python is not available on my side (python3 is).
I do not think this is needed on arm no.

> 
>>> 
>>>>> --- /dev/null
>>>>> +++ b/config/Darwin.mk
>>>>> @@ -0,0 +1,7 @@
>>>>> +# Use GNU tool definitions as the tools we are using are either GNU compatible
>>>>> +# or we only use features which are supported on Mac OS.
>>>>> +include $(XEN_ROOT)/config/StdGNU.mk
>>>>> +
>>>>> +# Xen uses Linux'es ABI so we are cross compiling on Mac OS.
>>>>> +# Force COMPILE_ARCH to a fake value to make sure it is always the case.
>>>>> +XEN_COMPILE_ARCH = Darwin
>>>> 
>>>> I first wondered why you say "fake", seeing the file is named Darwin.mk. But
>>>> in Config.mk's cross-compile check the build host OS doesn't even matter. So
>>>> yes, it needs faking here for the time being.
>>> 
>>> Hm, setting it to "Darwin" seems weird to me.  I understand the
>>> purpose of this is to force the user to set XEN_TARGET_ARCH
>>> explicitly.  I however wouldn't see it as fully uncorrect to not set
>>> this.  It will then execute `uname -m` and get `arm64` back for Apple
>>> silicon macs (which is kind of OK?).  Other I suggest we use a non-OSX
>>> specific value here, so that if required we could distinguish this
>>> case where the user is expected to provide XEN_COMPILE_ARCH.
>>> 
>>> Maybe XEN_COMPILE_ARCH = { unknown | undefined }?
>> 
>> I am ok to change this with either but maybe unsupported could be
>> a third choice?
> 
> No strong opinion for either naming, as long as we don't explicitly
> use "Darwin".

ok let's use "unsupported"

I will push a v4 with the commit message and Darwin.mk fixes

Cheers
Bertrand

> 
> Thanks, Roger.