[meta-virtualization] [PATCH 1/7] xen: Define the standard values needed for stubdoms

[Christopher Clark]

On Mon, Mar 5, 2018 at 7:35 AM, Kurt Bodiker <kurt.bodiker at braintrust-us.com
> wrote:

> From: kebodiker <kurt.bodiker at braintrust-us.com>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-virtualization/attachments/20180308/600ba8fc/attachment.html>