From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 141C3C433EF for ; Tue, 21 Dec 2021 04:39:27 +0000 (UTC) Received: from mail-vk1-f177.google.com (mail-vk1-f177.google.com [209.85.221.177]) by mx.groups.io with SMTP id smtpd.web10.2248.1640061566051290077 for ; Mon, 20 Dec 2021 20:39:26 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=nK3auiX7; spf=pass (domain: gmail.com, ip: 209.85.221.177, mailfrom: christopher.w.clark@gmail.com) Received: by mail-vk1-f177.google.com with SMTP id b77so2021235vka.11 for ; Mon, 20 Dec 2021 20:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jX6XlrRwWcNpYCO3tskRaDf23qqastjYwIDiKil4hQ4=; b=nK3auiX7F9Zj6GW7U+0EgaZkFXhf/Qj7ecg/K9hCCPfqABVDcgRiWmEWCd8S0THx8Z Vc0tv3JIOTqWPHhru5huvTo0ieT/vXkIrDr/vTeXwY1lqknZv8MVkLQQKlHv2cN6nQkW LDHhSJ/cgF5qFidfqwe6JC0QPiTPJF6EWA236KG8IBotVvqatQos/k7ooQj98FjT0iuA tM3xNptRMSO32K7XOxjlNP1OswIcKCJdJ116YQweoPtK6XDC4liztpg9k1da0t1mvoyE E17KG0aRSjWuVW8SlDPIZw3JggIBQDxu6nZ0MtCVer2y6nnC/sjumRJnmV4jFe65wOeI QBqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jX6XlrRwWcNpYCO3tskRaDf23qqastjYwIDiKil4hQ4=; b=j4IexXLPw3NBszku6JZAba5a2NXzZ+jEg9P3IXBvYgg66wJurJNcU2fcd+I0EEAD7E sykN5KwF72zHkapcbvpb/bkoijgpAT42ucn6hFD7H3sLPFJUAobtWO2BBPM4upfnpfBC rAsn8Z2F6Brfrp/Xo+o3B2EuEr5MuELBXlA5+zohi859vfnUrUiv8aWDvCyy6sQp4IFm zfAF4zo5LPf9CCbfCLAoTSLHTesAnKWUfjQlqf8wVIzHSdJWwRBV/zXCpqTDhMmUS2Af OnZJFl5CBPuqqtxSlw45cogHCaA1xYW1lpxgMzUN6/SAyVTtanKh0aqco+s9ALqKK1Wf 6KeQ== X-Gm-Message-State: AOAM5334/sEtFOuhMCURyWXOC9Ay5AGtZ8x+vpKLDYUXJrZ0fQq/cpHP 2jm75bNLXGiOhV/GmIaJxbGOIhSftGYsR1FwJ1c= X-Google-Smtp-Source: ABdhPJyaf0R86WGxvV6zSA6tr45jEs6HPbocvECuikK0eylCBfAAaGcy9C75o8YDEWV8oA9WNoTldcmYNp7izYqDsC0= X-Received: by 2002:a1f:ff0a:: with SMTP id p10mr445297vki.1.1640061565098; Mon, 20 Dec 2021 20:39:25 -0800 (PST) MIME-Version: 1.0 References: <20211209135752.6872-1-kamil.dziezyk@arm.com> <20211209135752.6872-2-kamil.dziezyk@arm.com> In-Reply-To: <20211209135752.6872-2-kamil.dziezyk@arm.com> From: Christopher Clark Date: Mon, 20 Dec 2021 20:39:14 -0800 Message-ID: Subject: Re: [meta-virtualization][PATCH v2 2/3] xen: Clear TUNE_CCARGS for Xen build for aarch64 machines To: Kamil Dziezyk Cc: meta-virtualization@lists.yoctoproject.org, nd , Doug Goldstein Content-Type: multipart/alternative; boundary="000000000000ff5fb205d3a096db" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 21 Dec 2021 04:39:27 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/meta-virtualization/message/6984 --000000000000ff5fb205d3a096db Content-Type: text/plain; charset="UTF-8" On Thu, Dec 9, 2021 at 5:59 AM Kamil Dziezyk wrote: > Xen build may fail for arm machines that have enabled extra flags, > that can be enabled only for specific architecture version, e.g. armv8-2a. > Apologies for being slow to review this one. >From looking at "bitbake -e xen" for an example Raspberry Pi 4 aarch64 build configuration, the major variables that this affects looks like: CPP, CXX and EXTRA_CFLAGS_XEN_TOOLS. So is it the xen recipe or the xen-tools recipe that this patch is intended to fix the build for? (or both?) I can't immediately tell what compilation this fixes, but: I think that this change is probably OK for the hypervisor case, since TUNE_CCARGS is already excluded from the definition of CC for aarch64 for the hypervisor build, but for the tools it will affect the compiler flags, so: Do you really intend to drop all "-mcpu" and "-march" C compiler flags from the Xen tools build, for any aarch64 MACHINEs? Should your MACHINEs actually populate TUNE_CCARGS with those flags if they are not wanted for userspace software? -- or is there a problem that is specifically being encountered with the Xen tools software build? If so, I'd like to know a bit more about that -- and then this workaround may be OK if we can confirm that it doesn't negatively affect the MACHINEs that we care about, which include QemuArm64 and the Rpi4 as a reference platform. As an aside, I would like to remove the similar x86 logic from this recipe where TUNE_CCARGS is cleared to address the hvmloader build, and fix that in a better way. (That will be separate to this work.) The comment that is being added refers to "HVM-mode": is that term still accurate for Xen on Arm? The subject line for this patch should indicate both "xen" and "xen-tools", since this modifies xen.inc which is included by both recipes. I would encourage you to CC both myself and Doug on future posts of Xen-related patches, please. thanks Christopher > > Signed-off-by: Kamil Dziezyk > --- > recipes-extended/xen/xen.inc | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc > index d3c7a7d..9ac82ef 100644 > --- a/recipes-extended/xen/xen.inc > +++ b/recipes-extended/xen/xen.inc > @@ -102,6 +102,11 @@ EXTRA_CFLAGS_XEN_CORE="${DEBUG_PREFIX_MAP}" > # EXTRA_CFLAGS_XEN_TOOLS: so clear TUNE_CCARGS on x86 to prevent that. > TUNE_CCARGS:x86-64="" > > +# - The Xen build for aarch64 systems with HVM-mode enabled may include > +# architecture specific flags '-march=*' which causes build failure, so > clear > +# TUNE_CCARGS on aarch64 to prevent that. > +TUNE_CCARGS:aarch64="" > + > # - Yocto supplies the _FORTIFY_SOURCE flag via CC/CPP/CXX but then > passes the > # optimization -O via C*FLAGS which is problematic when the CFLAGS are > cleared > # within the build because compilation fails with the compiler stating > -- > 2.17.1 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#6973): > https://lists.yoctoproject.org/g/meta-virtualization/message/6973 > Mute This Topic: https://lists.yoctoproject.org/mt/87611981/3619036 > Group Owner: meta-virtualization+owner@lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [ > christopher.w.clark+meta-virt@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > > --000000000000ff5fb205d3a096db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 9, 2021 at 5:59 AM Kamil Dzie= zyk <kamil.dziezyk@arm.com&= gt; wrote:
Xen build may fail for arm machines that have enabled= extra flags,
that can be enabled only for specific architecture version, e.g. armv8-2a.<= br>

Apologies for being slow to review this= one.

From looking at "bitbake -e xen&qu= ot; for an example Raspberry Pi 4 aarch64 build configuration, the major va= riables that this affects looks like: CPP, CXX and=C2=A0EXTRA_CFLAGS_XEN_TO= OLS.
So is it the xen recipe or the xen-tools recipe that this pa= tch is intended to fix the build for? (or both?)

I can't immediately tell what compilation this fixes, but: I t= hink that this change is probably OK for the hypervisor case, since TUNE_CC= ARGS is already excluded from the definition of CC for aarch64 for the hype= rvisor build, but for the tools it will affect the compiler flags, so:

Do you really intend to drop all "-mcpu" and= "-march" C compiler flags from the Xen tools build, for any aarc= h64 MACHINEs? Should your MACHINEs actually populate TUNE_CCARGS with those= flags if they are not wanted for userspace software? -- or is there a prob= lem that is specifically being encountered with the Xen tools software buil= d? If so, I'd like to know a bit more about that -- and then this worka= round may be OK if we can confirm that it doesn't negatively affect the= MACHINEs that we care about, which include QemuArm64 and the Rpi4 as a ref= erence platform.

As an aside, I would like to= remove the similar x86 logic from this recipe where TUNE_CCARGS is cleared= to address the hvmloader build, and fix that in a better way. (That will b= e separate to this work.)

The comment that i= s being added refers to "HVM-mode": is that term still accurate f= or Xen on Arm?

The subject line for this= patch should indicate both "xen" and "xen-tools", sinc= e this modifies xen.inc which is included by both recipes. I would encourag= e you to CC both myself and Doug on future posts of Xen-related patches, pl= ease.

thanks

= Christopher

=C2=A0

Signed-off-by: Kamil Dziezyk <kamil.dziezyk@arm.com>
---
=C2=A0recipes-extended/xen/xen.inc | 5 +++++
=C2=A01 file changed, 5 insertions(+)

diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc index d3c7a7d..9ac82ef 100644
--- a/recipes-extended/xen/xen.inc
+++ b/recipes-extended/xen/xen.inc
@@ -102,6 +102,11 @@ EXTRA_CFLAGS_XEN_CORE=3D"${DEBUG_PREFIX_MAP}"= ;
=C2=A0#=C2=A0 =C2=A0EXTRA_CFLAGS_XEN_TOOLS: so clear TUNE_CCARGS on x86 to = prevent that.
=C2=A0TUNE_CCARGS:x86-64=3D""

+# - The Xen build for aarch64 systems with HVM-mode enabled may include +#=C2=A0 =C2=A0architecture specific flags '-march=3D*' which cause= s build failure, so clear
+#=C2=A0 =C2=A0TUNE_CCARGS on aarch64 to prevent that.
+TUNE_CCARGS:aarch64=3D""
+
=C2=A0# - Yocto supplies the _FORTIFY_SOURCE flag via CC/CPP/CXX but then p= asses the
=C2=A0#=C2=A0 =C2=A0optimization -O via C*FLAGS which is problematic when t= he CFLAGS are cleared
=C2=A0#=C2=A0 =C2=A0within the build because compilation fails with the com= piler stating
--
2.17.1


-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
Links: You receive all messages sent to this group.
View/Reply Online (#6973): https://= lists.yoctoproject.org/g/meta-virtualization/message/6973
Mute This Topic: https://lists.yoctoproject.org/mt= /87611981/3619036
Group Owner: meta-virtualization+owner@lists.yoctoproject.org<= /a>
Unsubscribe: https://lists.yoctoproject.or= g/g/meta-virtualization/unsub [christopher.w.clark+meta-virt@gmail.= com]
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-

--000000000000ff5fb205d3a096db--