From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id C14BEE01061; Thu, 8 Mar 2018 18:23:38 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-HAM-Report: * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (christopher.w.clark[at]gmail.com) * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no * trust * [209.85.220.181 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 8CD60E0106F for ; Thu, 8 Mar 2018 18:23:35 -0800 (PST) Received: by mail-qk0-f181.google.com with SMTP id f25so2115800qkm.0 for ; Thu, 08 Mar 2018 18:23:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uVKLWt59e2BnqSa53c+2jsVIcfcshVlFm17q8vPeYh8=; b=gAbFLBxVvmOiisbTRgNQne6CLGVF7Pr1KaOKzjLJJnvpnxJBzuh479/3lNWTbeXAFU 1VpV6xaVD0Z8V6SWRS2saXwaxqja6oLZKc/254U2UOakID3BmHQhQSHF+mnS/YkpI7y2 PQDSc3Z8H/jLbAxJlG7b8u2BxhAbO6GrJhDKqzCfjjQqt6pW+8EQJugv5kEAZbzLo15m qofJFKASFuATpowkvzGDA89vqJg4WBwy8Jso9Q7acGoP898OfyYq+4EZ6mE0i80tuQKJ /SBtKgjrXbXkauDrJ6V9SQXJhV+qDEsNwwEwH9nuxOTP9RujAySHG8Ymy72iRY1B7472 b9GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uVKLWt59e2BnqSa53c+2jsVIcfcshVlFm17q8vPeYh8=; b=ctNZWM+oiOtbwsUZCmuip/YgmR5f5jfEIL9QXVdjjvr1Y2Jfa12jOg/isFNqeLz3sT Un3fuDHVMX6d+yWR3i17C9+4FwTZWdSADv9M6hUiXKFf/iMSvDxR7fdwbHhSAlIFIau9 nKtAb4BXcSdeYupFL9JaLMhOyn/uOo/uqRWScI0GLcwwf2x0UOXEcUWoCOidvyZfTBHS 4Y9oRxaktHNhtP0EaEiwbZPU1q5CZtXa8xRLc5dPMIePfL4aZch6jrwXIw53VJxw1iWc 3+54TkTL4hWnd8h9jyF78/4hyq7QwpjHKWRQ8KzQOpj0xPpt7HrvMXZ/H9Qsrryu6OlS Bqaw== X-Gm-Message-State: AElRT7EehNW3YZIhPCX5+Vd8XSrT/Hr4Hd+2vLnO+/ipGrbEFlURBzxx kiMqZUIk6a8FnDBWdvBkziDKFGZNYUVVLft2BnI= X-Google-Smtp-Source: AG47ELuXXKxxgVo/pDDNqVVNsymV7VXSL4jampJTXjZPTAuGmF3cb0AYkxdg+SiUPrNsV156eQHA3nuXFKyNIrX/lfo= X-Received: by 10.55.182.68 with SMTP id g65mr26184042qkf.41.1520562214780; Thu, 08 Mar 2018 18:23:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.98.178 with HTTP; Thu, 8 Mar 2018 18:23:34 -0800 (PST) In-Reply-To: References: From: Christopher Clark Date: Thu, 8 Mar 2018 18:23:34 -0800 Message-ID: To: Kurt Bodiker Cc: meta-virtualization@yoctoproject.org Subject: Re: [PATCH 1/7] xen: Define the standard values needed for stubdoms X-BeenThere: meta-virtualization@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Discussion of layer enabling hypervisor, virtualization tool stack, and cloud support" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2018 02:23:38 -0000 Content-Type: multipart/alternative; boundary="94eb2c060d1eabc88d0566f17aa4" --94eb2c060d1eabc88d0566f17aa4 Content-Type: text/plain; charset="UTF-8" On Mon, Mar 5, 2018 at 7:35 AM, Kurt Bodiker wrote: > From: kebodiker > > This commit introduces the stubdom.inc file that is required for each > recipe that is/will be built for Xen stubdomains. > > +# Couldn't find any other way to access the version of Xen used as a > dependency. > +# This version number needs changed to match version of Xen recipe used > in builds. > +XEN_VERSION = "4.9.0" > :( I understand the challenge here and sadly I don't have a better recommendation, but: would putting a scope on the DEPEND enable the build to fail fast in case of a mismatch? ie: DEPENDS = "xen (= ${XEN_VERSION}-r0)" I don't much like the "-r0" tail on that though -- anyone have any better suggestion? > +# Not sure if we need to (or even can) support 32-bit stubdoms > +# If we we do not need to support the 32-bit environment, then this > section and the > +# export statement afterwards can be removed. > OpenXT uses 32-bit stubdomains - though they are not based on mini-os. 32-bit PV domains have different isolation properties to 64-bit domains, due to the way the pagetables are managed and as seen by their differing Meltdown exposure, so please do leave the code to support 32-bit stubdoms in there as they are valued. I have a slight preference for dropping (or revising) the comment. > +STUBDOM_CPPFLAGS += "-isystem ${WORKDIR}/mini-os/include" > +STUBDOM_CPPFLAGS += "-D__MINIOS__ -DHAVE_LIBC" > +STUBDOM_CPPFLAGS += "-isystem ${WORKDIR}/mini-os/include/posix" > +STUBDOM_CPPFLAGS += "-isystem ${RECIPE_SYSROOT}/usr/include/ > xenstore-compat" > +STUBDOM_CPPFLAGS += "-isystem ${WORKDIR}/mini-os/include/x86 -isystem > ${WORKDIR}/mini-os/include/x86/${XEN_TARGET_ARCH}" > +STUBDOM_CPPFLAGS += "-U __linux__ -U __FreeBSD__ -U __sun__" > +STUBDOM_CPPFLAGS += "-nostdinc" > +CPPFLAGS_INCLUDE_DIR = "-isystem ${RECIPE_SYSROOT}/cross-root-$ > {XEN_TARGET_ARCH}/${GNU_TARGET_ARCH}-xen-elf/include" > +STUBDOM_CPPFLAGS += "${CPPFLAGS_INCLUDE_DIR}" > +STUBDOM_CPPFLAGS += "-isystem ${RECIPE_SYSROOT}/cross-root-${XEN_TARGET_ARCH}/lwip/include > -isystem ${RECIPE_SYSROOT}/cross-root-${XEN_TARGET_ARCH}/lwip/ > include/ipv4" > +STUBDOM_CPPFLAGS += "-isystem ${RECIPE_SYSROOT}/usr/include/xen" > The define for CPPFLAGS_INCLUDE_DIR in the middle of the above would better moved elsewhere. Would a multi-line define would be more OE-style than the series of lines all appending to the same variable? + > +STUBDOM_CFLAGS += "-mno-red-zone -O1 -fno-omit-frame-pointer -m64 > -fno-reorder-blocks -fno-asynchronous-unwind-tables -DBUILD_ID > -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes > -Wdeclaration-after-statement -Wno-unused-but-set-variable > -Wno-unused-local-typedefs -fno-stack-protector -fno-exceptions" > The above would also be slightly nicer split over multiple (shorter) lines. thanks Christopher --94eb2c060d1eabc88d0566f17aa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Mon, Mar 5, 2018 at 7:35 AM, Kurt Bodiker <kurt.bodiker@b= raintrust-us.com> wrote:
From: kebodiker <kurt.bodiker@braintrust-us.com>

This commit introduces the stubdom.inc file that is required for each
recipe that is/will be built for Xen stubdomains.

=
=C2=A0
+#= Couldn't find any other way to access the version of Xen used as a dep= endency.
+# This version number needs changed to match version of Xen recipe=C2=A0 u= sed in builds.
+XEN_VERSION =3D "4.9.0"


=
:( I understand the challenge here and sadly I don't ha= ve a better recommendation, but: would putting a scope on the DEPEND enable= the build to fail fast in case
of a mismatch?=C2=A0 ie:

=C2=A0 =C2=A0 DEPENDS =3D "xen (=3D ${XEN_VERSION}-r0= )"

I don't much like the "-r0" = tail on that though -- anyone have any better suggestion?
<= br>
=C2=A0
+# Not sure if we need to (or even can) support 32-bit stubdoms
+# If we we do not need to support the 32-bit environment, then this sectio= n and the
+# export statement afterwards can be removed.

OpenXT uses 32-bit stubdomains - though they are not based on = mini-os. 32-bit PV domains have different isolation properties to 64-bit do= mains, due to the way the
pagetables are managed and as seen by t= heir differing Meltdown exposure, so please do leave the code to support 32= -bit stubdoms in there as they are valued.

I have = a slight preference for dropping (or revising) the comment.


+STUBDOM_CPPFLAGS +=3D "-isystem ${WORKDIR}/mini-os/include"
+STUBDOM_CPPFLAGS +=3D "-D__MINIOS__ -DHAVE_LIBC"
+STUBDOM_CPPFLAGS +=3D "-isystem ${WORKDIR}/mini-os/include/posix= "
+STUBDOM_CPPFLAGS +=3D "-isystem ${RECIPE_SYSROOT}/usr/include/xe= nstore-compat"
+STUBDOM_CPPFLAGS +=3D "-isystem ${WORKDIR}/mini-os/include/x86 -isyst= em ${WORKDIR}/mini-os/include/x86/${XEN_TARGET_ARCH}"
+STUBDOM_CPPFLAGS +=3D "-U __linux__ -U __FreeBSD__ -U __sun__" +STUBDOM_CPPFLAGS +=3D "-nostdinc"
+CPPFLAGS_INCLUDE_DIR =3D "-isystem ${RECIPE_SYSROOT}/cross-root-${XEN_TARGET_ARCH}/${GNU_TARGET_ARCH}-xen-elf/include"
+STUBDOM_CPPFLAGS +=3D "${CPPFLAGS_INCLUDE_DIR}"
+STUBDOM_CPPFLAGS +=3D "-isystem ${RECIPE_SYSROOT}/cross-root-${X= EN_TARGET_ARCH}/lwip/include -isystem ${RECIPE_SYSROOT}/cross-root-${X= EN_TARGET_ARCH}/lwip/include/ipv4"
+STUBDOM_CPPFLAGS +=3D "-isystem ${RECIPE_SYSROOT}/usr/include/xe= n"

The define for CPPFLAGS_INCLUDE= _DIR in the middle of the above would better moved elsewhere.
Would a multi-line define would be more OE-style than the serie= s of lines all appending to the same variable?

+
+STUBDOM_CFLAGS +=3D "-mno-red-zone -O1 -fno-omit-frame-pointer -m64 -= fno-reorder-blocks -fno-asynchronous-unwind-tables -DBUILD_ID -fno-str= ict-aliasing -std=3Dgnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-sta= tement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -fno-stack-p= rotector -fno-exceptions"

The abov= e would also be slightly nicer split over multiple (shorter) lines.

thanks

Christopher
--94eb2c060d1eabc88d0566f17aa4--