Re: [PATCH v4] xen: Add Darwin.mk for GNU toolchains

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Jan,

> On 9 Feb 2026, at 10:45, Jan Beulich <jbeulich@xxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxx>
>>>> 
>>>> Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>>>> 
>>>> 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.