Re: kernel: fix hv tools build for arm64 when cross-built

[Wei Liu <wei.liu@kernel.org>]

On Tue, Dec 10, 2024 at 06:34:28PM +0000, Wei Liu wrote:
> On Mon, Dec 09, 2024 at 07:39:10PM -0800, Saurabh Singh Sengar wrote:
> > On Mon, Dec 09, 2024 at 06:46:42PM +0000, Wei Liu wrote:
> > > On Mon, Dec 09, 2024 at 12:30:35AM -0800, Saurabh Singh Sengar wrote:
> > > > On Mon, Dec 09, 2024 at 12:44:22AM +0000, Wei Liu wrote:
> > > > > On Wed, Oct 23, 2024 at 02:01:12PM +0000, Adrian Vladu wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > While trying to build the LIS daemons for Flatcar Container Linux for
> > > > > > ARM64 (https://www.flatcar.org/), as we are doing Gentoo based
> > > > > > cross-building from X64 boxes, there was an error while building those
> > > > > > daemons, because the cross-compile scenario was not working, as ` ARCH
> > > > > > := $(shell uname -m 2>/dev/null)` always returns `x86_64`.
> > > > > > 
> > > > > > I have a working patch for the Linux kernel here that was already
> > > > > > applied in the Flatcar context and it works:
> > > > > > https://github.com/flatcar/scripts/blob/94b1df1b19449eb5aa967fd48ba4c1f4a6d5f415/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/6.10/z0008-tools-hv-fix-cross-compilation-for-ARM64.patch
> > > > > > 
> > > > > > Raw patch link here:
> > > > > > https://raw.githubusercontent.com/flatcar/scripts/94b1df1b19449eb5aa967fd48ba4c1f4a6d5f415/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/6.10/z0008-tools-hv-fix-cross-compilation-for-ARM64.patch
> > > > > > 
> > > > > > Sorry for the delivery method via github link, but I cannot send
> > > > > > proper patches from my work email address currently, as the email
> > > > > > server does not support it.
> > > > > > 
> > > > > > Please let me know if I need to send the patch via the recommended way
> > > > > > or if the patch can be used directly.
> > > > > > 
> > > > > > Also, maybe there is a better way to address the cross-compilation
> > > > > > issue, I just wanted to report the bug and also provide a possible
> > > > > > fix.
> > > > > 
> > > > > Saurabh added the ARCH variable. He's CCed.
> > > > > 
> > > > > BTW I think your patch can be simplified by using
> > > > >   ARCH ?= $(shell uname -m 2>/dev/null)
> > > > > instead of the ifeq test in your patch.
> > > > 
> > > > Agree, this is better way to handle it.
> > > > 
> > > > > 
> > > > > I don't think that's correct. ARCH will be set to the correct value by
> > > > > Kbuild. 
> > > > 
> > > > If we build locally on ARM64, there is a chance that ARCH may not be set,
> > > > leading to build failures for arm64. IMO we should provide a fallback
> > > > option for local builds when ARCH is not set.
> > > 
> > > How do you build locally? Even if you build those tools in tools/hv, it
> > > still uses the Kbuild system, which sets ARCH to the correct value,
> > > right?
> > > 
> > 
> > I have tested your patch in ARM64 VM, can see the build failure. Here's the
> > exact details how I tested:
> > 
> > 
> > azureuser@ARM64-ubunutu24:/work/linux-next$ cd tools/hv/
> > azureuser@ARM64-ubunutu24:/work/linux-next/tools/hv$ make
> > make[1]: Entering directory '/work/linux-next/tools/hv'
> >   CC      hv_kvp_daemon.o
> >   LD      hv_kvp_daemon-in.o
> > make[1]: Leaving directory '/work/linux-next/tools/hv'
> >   LINK    hv_kvp_daemon
> > make[1]: Entering directory '/work/linux-next/tools/hv'
> >   CC      hv_vss_daemon.o
> >   LD      hv_vss_daemon-in.o
> > make[1]: Leaving directory '/work/linux-next/tools/hv'
> >   LINK    hv_vss_daemon
> > make[1]: Entering directory '/work/linux-next/tools/hv'
> >   CC      hv_fcopy_uio_daemon.o
> >   CC      vmbus_bufring.o
> > vmbus_bufring.c:11:10: fatal error: emmintrin.h: No such file or directory
> >    11 | #include <emmintrin.h>
> >       |          ^~~~~~~~~~~~~
> 
> I see. I create an arm64 VM and reproduce the issue. The ARCH variable
> is not set.
> 
> That said, the build breaks because emmintrin.h is not available on
> arm64. It is only needed for _mm_pause().  There is maybe an
> architecture specific header file we can use to make it build.

Never mind. There are also open coded x86 assembly code in
vmbus_bufring.c. Let's fix the cross-compilation issue first.

Thanks,
Wei.