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=unknown, 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 toolchain from brew:
- brew install aarch64-elf-gcc aarch64-elf-binutils
- cd xen
- make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=clang
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
---
Changes since v3:
- set XEN_COMPILE_ARCH to unknown instead of Darwin
- list binutils as a dependency to install in brew in commit message
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..176b27eac676
--- /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 = unknown
--
2.52.0On Fri, Feb 06, 2026 at 05:21:44PM +0100, 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=unknown, 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 toolchain from brew: > - brew install aarch64-elf-gcc aarch64-elf-binutils > - cd xen > - make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=clang Instead of `cd xen` I would use `make xen ...`. > > Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> One comment below. > --- > Changes since v3: > - set XEN_COMPILE_ARCH to unknown instead of Darwin > - list binutils as a dependency to install in brew in commit message > > 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..176b27eac676 > --- /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. Hm, is this actually fully true? What's the Linux ABI exactly here? FreeBSD builds Xen natively, and it's not using the Linux ABI. FreeBSD uses no specific -target to the compiler invocations, and the linker emulation is set to elf_x86_64_fbsd. I think the point here is that the toolchain must support building ELF objects / images, because that's the binary format supported by Xen. Whether it's Linux ELF or FreeBSD ELF doesn't make a difference for standalone environments like the Xen kernel. Thanks, Roger.
On 06.02.2026 18:25, Roger Pau Monné wrote: > On Fri, Feb 06, 2026 at 05:21:44PM +0100, 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=unknown, 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 toolchain from brew: >> - brew install aarch64-elf-gcc aarch64-elf-binutils >> - cd xen >> - make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=clang > > Instead of `cd xen` I would use `make xen ...`. There are subtle differences, though. (Really I first wondered whether you omitted -C ...) >> --- /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. > > Hm, is this actually fully true? What's the Linux ABI exactly here? > > FreeBSD builds Xen natively, and it's not using the Linux ABI. > FreeBSD uses no specific -target to the compiler invocations, and the > linker emulation is set to elf_x86_64_fbsd. > > I think the point here is that the toolchain must support building ELF > objects / images, because that's the binary format supported by Xen. > Whether it's Linux ELF or FreeBSD ELF doesn't make a difference for > standalone environments like the Xen kernel. It's the ELF SVR4 psABI that we're after. This is more than just building ELF objects: It's also about calling convention, for example. Which would not matter much if Xen code was all written in C, as the ABI Xen surfaces to guests is entirely different anyway. Jan
Hi Roger, > On 6 Feb 2026, at 18:25, Roger Pau Monné <roger.pau@citrix.com> wrote: > > On Fri, Feb 06, 2026 at 05:21:44PM +0100, 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=unknown, 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 toolchain from brew: >> - brew install aarch64-elf-gcc aarch64-elf-binutils >> - cd xen >> - make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=clang > > Instead of `cd xen` I would use `make xen ...`. Ack the 'cd xen' line is useless and should be removed. > >> >> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com> > > Acked-by: Roger Pau Monné <roger.pau@citrix.com> > > One comment below. > >> --- >> Changes since v3: >> - set XEN_COMPILE_ARCH to unknown instead of Darwin >> - list binutils as a dependency to install in brew in commit message >> >> 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..176b27eac676 >> --- /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. > > Hm, is this actually fully true? What's the Linux ABI exactly here? > > FreeBSD builds Xen natively, and it's not using the Linux ABI. > FreeBSD uses no specific -target to the compiler invocations, and the > linker emulation is set to elf_x86_64_fbsd. > > I think the point here is that the toolchain must support building ELF > objects / images, because that's the binary format supported by Xen. > Whether it's Linux ELF or FreeBSD ELF doesn't make a difference for > standalone environments like the Xen kernel. This file is also use while compiling the tools and for those you definitely to cross compile as they depend on Linux ABI. Maybe that works on BSD but i doubt this would be the case on mac os. Maybe we could simplify the sentence to not say anything we are unsure: # Cross compile on Mac OS Tell me if that works for you and i can submit a v5 or this might be possible to fix on commit. Cheers Bertrand > > Thanks, Roger.
On Mon, Feb 09, 2026 at 07:30:30AM +0000, Bertrand Marquis wrote:
> Hi Roger,
>
> > On 6 Feb 2026, at 18:25, Roger Pau Monné <roger.pau@citrix.com> wrote:
> >
> > On Fri, Feb 06, 2026 at 05:21:44PM +0100, 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=unknown, 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 toolchain from brew:
> >> - brew install aarch64-elf-gcc aarch64-elf-binutils
> >> - cd xen
> >> - make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=clang
> >
> > Instead of `cd xen` I would use `make xen ...`.
>
> Ack the 'cd xen' line is useless and should be removed.
>
> >
> >>
> >> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
> >
> > Acked-by: Roger Pau Monné <roger.pau@citrix.com>
> >
> > One comment below.
> >
> >> ---
> >> Changes since v3:
> >> - set XEN_COMPILE_ARCH to unknown instead of Darwin
> >> - list binutils as a dependency to install in brew in commit message
> >>
> >> 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..176b27eac676
> >> --- /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.
> >
> > Hm, is this actually fully true? What's the Linux ABI exactly here?
> >
> > FreeBSD builds Xen natively, and it's not using the Linux ABI.
> > FreeBSD uses no specific -target to the compiler invocations, and the
> > linker emulation is set to elf_x86_64_fbsd.
> >
> > I think the point here is that the toolchain must support building ELF
> > objects / images, because that's the binary format supported by Xen.
> > Whether it's Linux ELF or FreeBSD ELF doesn't make a difference for
> > standalone environments like the Xen kernel.
>
> This file is also use while compiling the tools and for those you definitely
> to cross compile as they depend on Linux ABI.
I'm not an expert on this at all, but IMO the tools don't depend on
the Linux ABI at all. Anyone can add the minimal OS-specific bindings
required for the tools to work on environments different than Linux.
We currently have {Net,Free}BSD and Linux. In the past we also had
Solaris, but that has bit rotten.
> Maybe that works on BSD
> but i doubt this would be the case on mac os.
I doubt we would ever have any need to build an OSX native toolchain,
as it's unlikely (?) that we will ever get Xen support in the Darwin
kernel.
> Maybe we could simplify the sentence to not say anything we are unsure:
>
> # Cross compile on Mac OS
>
> Tell me if that works for you and i can submit a v5 or this might be possible to
> fix on commit.
I'm fine with it, I would like to hear Jan's opinion.
Thanks, Roger.
On 09.02.2026 10:11, Roger Pau Monné wrote:
> On Mon, Feb 09, 2026 at 07:30:30AM +0000, Bertrand Marquis wrote:
>> Hi Roger,
>>
>>> On 6 Feb 2026, at 18:25, Roger Pau Monné <roger.pau@citrix.com> wrote:
>>>
>>> On Fri, Feb 06, 2026 at 05:21:44PM +0100, 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=unknown, 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 toolchain from brew:
>>>> - brew install aarch64-elf-gcc aarch64-elf-binutils
>>>> - cd xen
>>>> - make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=clang
>>>
>>> Instead of `cd xen` I would use `make xen ...`.
>>
>> Ack the 'cd xen' line is useless and should be removed.
>>
>>>
>>>>
>>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>>
>>> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
>>>
>>> One comment below.
>>>
>>>> ---
>>>> Changes since v3:
>>>> - set XEN_COMPILE_ARCH to unknown instead of Darwin
>>>> - list binutils as a dependency to install in brew in commit message
>>>>
>>>> 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..176b27eac676
>>>> --- /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.
>>>
>>> Hm, is this actually fully true? What's the Linux ABI exactly here?
>>>
>>> FreeBSD builds Xen natively, and it's not using the Linux ABI.
>>> FreeBSD uses no specific -target to the compiler invocations, and the
>>> linker emulation is set to elf_x86_64_fbsd.
>>>
>>> I think the point here is that the toolchain must support building ELF
>>> objects / images, because that's the binary format supported by Xen.
>>> Whether it's Linux ELF or FreeBSD ELF doesn't make a difference for
>>> standalone environments like the Xen kernel.
>>
>> This file is also use while compiling the tools and for those you definitely
>> to cross compile as they depend on Linux ABI.
>
> I'm not an expert on this at all, but IMO the tools don't depend on
> the Linux ABI at all. Anyone can add the minimal OS-specific bindings
> required for the tools to work on environments different than Linux.
> We currently have {Net,Free}BSD and Linux. In the past we also had
> Solaris, but that has bit rotten.
>
>> Maybe that works on BSD
>> but i doubt this would be the case on mac os.
>
> I doubt we would ever have any need to build an OSX native toolchain,
> as it's unlikely (?) that we will ever get Xen support in the Darwin
> kernel.
If Darwin has some way to load "modules" (e.g. drivers) into the kernel, it
may in principle be possible to run OSX as a HVM-Dom0, with a Xen driver
loaded separately. That's far fetched, I know.
>> Maybe we could simplify the sentence to not say anything we are unsure:
>>
>> # Cross compile on Mac OS
>>
>> Tell me if that works for you and i can submit a v5 or this might be possible to
>> fix on commit.
>
> I'm fine with it, I would like to hear Jan's opinion.
As long as it's clear that all of this is only about building the hypervisor
(which doesn't look to be the case right now beyond the example given in the
commit message, which may be taken as really only an example), that's okay
[1]. I'd still prefer to mention the SVR4 ABI here, though, to at least
somewhat explain the "always cross" aspect.
I can make edits while committing, but I'm unsure whether that's wanted in
this case.
Jan
[1] Yet better might be if we refused to build other than the hypervisor.
I'm unsure though how easy it would be to achieve that in an at least
halfway tidy manner.
Hi Jan,
> On 9 Feb 2026, at 10:45, Jan Beulich <jbeulich@suse.com> wrote:
>
> On 09.02.2026 10:11, Roger Pau Monné wrote:
>> On Mon, Feb 09, 2026 at 07:30:30AM +0000, Bertrand Marquis wrote:
>>> Hi Roger,
>>>
>>>> On 6 Feb 2026, at 18:25, Roger Pau Monné <roger.pau@citrix.com> wrote:
>>>>
>>>> On Fri, Feb 06, 2026 at 05:21:44PM +0100, 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=unknown, 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 toolchain from brew:
>>>>> - brew install aarch64-elf-gcc aarch64-elf-binutils
>>>>> - cd xen
>>>>> - make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=clang
>>>>
>>>> Instead of `cd xen` I would use `make xen ...`.
>>>
>>> Ack the 'cd xen' line is useless and should be removed.
>>>
>>>>
>>>>>
>>>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>>>
>>>> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
>>>>
>>>> One comment below.
>>>>
>>>>> ---
>>>>> Changes since v3:
>>>>> - set XEN_COMPILE_ARCH to unknown instead of Darwin
>>>>> - list binutils as a dependency to install in brew in commit message
>>>>>
>>>>> 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..176b27eac676
>>>>> --- /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.
>>>>
>>>> Hm, is this actually fully true? What's the Linux ABI exactly here?
>>>>
>>>> FreeBSD builds Xen natively, and it's not using the Linux ABI.
>>>> FreeBSD uses no specific -target to the compiler invocations, and the
>>>> linker emulation is set to elf_x86_64_fbsd.
>>>>
>>>> I think the point here is that the toolchain must support building ELF
>>>> objects / images, because that's the binary format supported by Xen.
>>>> Whether it's Linux ELF or FreeBSD ELF doesn't make a difference for
>>>> standalone environments like the Xen kernel.
>>>
>>> This file is also use while compiling the tools and for those you definitely
>>> to cross compile as they depend on Linux ABI.
>>
>> I'm not an expert on this at all, but IMO the tools don't depend on
>> the Linux ABI at all. Anyone can add the minimal OS-specific bindings
>> required for the tools to work on environments different than Linux.
>> We currently have {Net,Free}BSD and Linux. In the past we also had
>> Solaris, but that has bit rotten.
>>
>>> Maybe that works on BSD
>>> but i doubt this would be the case on mac os.
>>
>> I doubt we would ever have any need to build an OSX native toolchain,
>> as it's unlikely (?) that we will ever get Xen support in the Darwin
>> kernel.
>
> If Darwin has some way to load "modules" (e.g. drivers) into the kernel, it
> may in principle be possible to run OSX as a HVM-Dom0, with a Xen driver
> loaded separately. That's far fetched, I know.
>
>>> Maybe we could simplify the sentence to not say anything we are unsure:
>>>
>>> # Cross compile on Mac OS
>>>
>>> Tell me if that works for you and i can submit a v5 or this might be possible to
>>> fix on commit.
>>
>> I'm fine with it, I would like to hear Jan's opinion.
>
> As long as it's clear that all of this is only about building the hypervisor
> (which doesn't look to be the case right now beyond the example given in the
> commit message, which may be taken as really only an example), that's okay
> [1]. I'd still prefer to mention the SVR4 ABI here, though, to at least
> somewhat explain the "always cross" aspect.
>
> I can make edits while committing, but I'm unsure whether that's wanted in
> this case.
I would suggest:
Cross compile on Mac OS, only hypervisor build has been tested, no tools
Please do the following edits on commit if that's ok for you :
- remove 'cd xen' from commit message
- use previous comment in Darwin.mk
Othewise happy to submit a v5
Cheers
Bertrand
>
> Jan
>
> [1] Yet better might be if we refused to build other than the hypervisor.
> I'm unsure though how easy it would be to achieve that in an at least
> halfway tidy manner.
On 09.02.2026 11:02, Bertrand Marquis wrote:
> Hi Jan,
>
>> On 9 Feb 2026, at 10:45, Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 09.02.2026 10:11, Roger Pau Monné wrote:
>>> On Mon, Feb 09, 2026 at 07:30:30AM +0000, Bertrand Marquis wrote:
>>>> Hi Roger,
>>>>
>>>>> On 6 Feb 2026, at 18:25, Roger Pau Monné <roger.pau@citrix.com> wrote:
>>>>>
>>>>> On Fri, Feb 06, 2026 at 05:21:44PM +0100, 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=unknown, 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 toolchain from brew:
>>>>>> - brew install aarch64-elf-gcc aarch64-elf-binutils
>>>>>> - cd xen
>>>>>> - make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=clang
>>>>>
>>>>> Instead of `cd xen` I would use `make xen ...`.
>>>>
>>>> Ack the 'cd xen' line is useless and should be removed.
>>>>
>>>>>
>>>>>>
>>>>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>>>>
>>>>> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
>>>>>
>>>>> One comment below.
>>>>>
>>>>>> ---
>>>>>> Changes since v3:
>>>>>> - set XEN_COMPILE_ARCH to unknown instead of Darwin
>>>>>> - list binutils as a dependency to install in brew in commit message
>>>>>>
>>>>>> 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..176b27eac676
>>>>>> --- /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.
>>>>>
>>>>> Hm, is this actually fully true? What's the Linux ABI exactly here?
>>>>>
>>>>> FreeBSD builds Xen natively, and it's not using the Linux ABI.
>>>>> FreeBSD uses no specific -target to the compiler invocations, and the
>>>>> linker emulation is set to elf_x86_64_fbsd.
>>>>>
>>>>> I think the point here is that the toolchain must support building ELF
>>>>> objects / images, because that's the binary format supported by Xen.
>>>>> Whether it's Linux ELF or FreeBSD ELF doesn't make a difference for
>>>>> standalone environments like the Xen kernel.
>>>>
>>>> This file is also use while compiling the tools and for those you definitely
>>>> to cross compile as they depend on Linux ABI.
>>>
>>> I'm not an expert on this at all, but IMO the tools don't depend on
>>> the Linux ABI at all. Anyone can add the minimal OS-specific bindings
>>> required for the tools to work on environments different than Linux.
>>> We currently have {Net,Free}BSD and Linux. In the past we also had
>>> Solaris, but that has bit rotten.
>>>
>>>> Maybe that works on BSD
>>>> but i doubt this would be the case on mac os.
>>>
>>> I doubt we would ever have any need to build an OSX native toolchain,
>>> as it's unlikely (?) that we will ever get Xen support in the Darwin
>>> kernel.
>>
>> If Darwin has some way to load "modules" (e.g. drivers) into the kernel, it
>> may in principle be possible to run OSX as a HVM-Dom0, with a Xen driver
>> loaded separately. That's far fetched, I know.
>>
>>>> Maybe we could simplify the sentence to not say anything we are unsure:
>>>>
>>>> # Cross compile on Mac OS
>>>>
>>>> Tell me if that works for you and i can submit a v5 or this might be possible to
>>>> fix on commit.
>>>
>>> I'm fine with it, I would like to hear Jan's opinion.
>>
>> As long as it's clear that all of this is only about building the hypervisor
>> (which doesn't look to be the case right now beyond the example given in the
>> commit message, which may be taken as really only an example), that's okay
>> [1]. I'd still prefer to mention the SVR4 ABI here, though, to at least
>> somewhat explain the "always cross" aspect.
>>
>> I can make edits while committing, but I'm unsure whether that's wanted in
>> this case.
>
> I would suggest:
>
> Cross compile on Mac OS, only hypervisor build has been tested, no tools
>
> Please do the following edits on commit if that's ok for you :
> - remove 'cd xen' from commit message
> - use previous comment in Darwin.mk
There have been several "previous" comments there, so I think in this case
it may indeed be better ...
> Othewise happy to submit a v5
... if you do this. I'm sorry, it's quite a bit of bike-shedding on "merely"
commentary, yet I think we want to avoid misleading people.
Jan
Hi Jan,
> On 9 Feb 2026, at 11:17, Jan Beulich <jbeulich@suse.com> wrote:
>
> On 09.02.2026 11:02, Bertrand Marquis wrote:
>> Hi Jan,
>>
>>> On 9 Feb 2026, at 10:45, Jan Beulich <jbeulich@suse.com> wrote:
>>>
>>> On 09.02.2026 10:11, Roger Pau Monné wrote:
>>>> On Mon, Feb 09, 2026 at 07:30:30AM +0000, Bertrand Marquis wrote:
>>>>> Hi Roger,
>>>>>
>>>>>> On 6 Feb 2026, at 18:25, Roger Pau Monné <roger.pau@citrix.com> wrote:
>>>>>>
>>>>>> On Fri, Feb 06, 2026 at 05:21:44PM +0100, 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=unknown, 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 toolchain from brew:
>>>>>>> - brew install aarch64-elf-gcc aarch64-elf-binutils
>>>>>>> - cd xen
>>>>>>> - make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-elf- HOSTCC=clang
>>>>>>
>>>>>> Instead of `cd xen` I would use `make xen ...`.
>>>>>
>>>>> Ack the 'cd xen' line is useless and should be removed.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>>>>>
>>>>>> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
>>>>>>
>>>>>> One comment below.
>>>>>>
>>>>>>> ---
>>>>>>> Changes since v3:
>>>>>>> - set XEN_COMPILE_ARCH to unknown instead of Darwin
>>>>>>> - list binutils as a dependency to install in brew in commit message
>>>>>>>
>>>>>>> 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..176b27eac676
>>>>>>> --- /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.
>>>>>>
>>>>>> Hm, is this actually fully true? What's the Linux ABI exactly here?
>>>>>>
>>>>>> FreeBSD builds Xen natively, and it's not using the Linux ABI.
>>>>>> FreeBSD uses no specific -target to the compiler invocations, and the
>>>>>> linker emulation is set to elf_x86_64_fbsd.
>>>>>>
>>>>>> I think the point here is that the toolchain must support building ELF
>>>>>> objects / images, because that's the binary format supported by Xen.
>>>>>> Whether it's Linux ELF or FreeBSD ELF doesn't make a difference for
>>>>>> standalone environments like the Xen kernel.
>>>>>
>>>>> This file is also use while compiling the tools and for those you definitely
>>>>> to cross compile as they depend on Linux ABI.
>>>>
>>>> I'm not an expert on this at all, but IMO the tools don't depend on
>>>> the Linux ABI at all. Anyone can add the minimal OS-specific bindings
>>>> required for the tools to work on environments different than Linux.
>>>> We currently have {Net,Free}BSD and Linux. In the past we also had
>>>> Solaris, but that has bit rotten.
>>>>
>>>>> Maybe that works on BSD
>>>>> but i doubt this would be the case on mac os.
>>>>
>>>> I doubt we would ever have any need to build an OSX native toolchain,
>>>> as it's unlikely (?) that we will ever get Xen support in the Darwin
>>>> kernel.
>>>
>>> If Darwin has some way to load "modules" (e.g. drivers) into the kernel, it
>>> may in principle be possible to run OSX as a HVM-Dom0, with a Xen driver
>>> loaded separately. That's far fetched, I know.
>>>
>>>>> Maybe we could simplify the sentence to not say anything we are unsure:
>>>>>
>>>>> # Cross compile on Mac OS
>>>>>
>>>>> Tell me if that works for you and i can submit a v5 or this might be possible to
>>>>> fix on commit.
>>>>
>>>> I'm fine with it, I would like to hear Jan's opinion.
>>>
>>> As long as it's clear that all of this is only about building the hypervisor
>>> (which doesn't look to be the case right now beyond the example given in the
>>> commit message, which may be taken as really only an example), that's okay
>>> [1]. I'd still prefer to mention the SVR4 ABI here, though, to at least
>>> somewhat explain the "always cross" aspect.
>>>
>>> I can make edits while committing, but I'm unsure whether that's wanted in
>>> this case.
>>
>> I would suggest:
>>
>> Cross compile on Mac OS, only hypervisor build has been tested, no tools
>>
>> Please do the following edits on commit if that's ok for you :
>> - remove 'cd xen' from commit message
>> - use previous comment in Darwin.mk
>
> There have been several "previous" comments there, so I think in this case
> it may indeed be better ...
>
>> Othewise happy to submit a v5
>
> ... if you do this. I'm sorry, it's quite a bit of bike-shedding on "merely"
> commentary, yet I think we want to avoid misleading people.
ok.
Cheers
Bertrand
>
> Jan
© 2016 - 2026 Red Hat, Inc.