Hi Roger, > On 6 Feb 2026, at 15:16, Roger Pau Monné <[email protected]> wrote: > > On Fri, Feb 06, 2026 at 01:34:23PM +0000, Bertrand Marquis wrote: >> >> >>> On 6 Feb 2026, at 14:29, Roger Pau Monné <[email protected]> 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 <[email protected]> >>>>> --- >>>>> 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.
