Re: Virtio on Xen with Rust
> On Apr 14, 2022, at 9:10 AM, Wei Liu wrote: > > On Thu, Apr 14, 2022 at 02:36:12PM +0100, Alex Bennée wrote: >> >> Wei Liu writes: >> >>> On Thu, Apr 14, 2022 at 12:07:10PM +, Andrew Cooper wrote: On 14/04/2022 12:45, Wei Liu wrote: > Hi Viresh > > This is very cool. > > On Thu, Apr 14, 2022 at 02:53:58PM +0530, Viresh Kumar wrote: >> +xen-devel >> >>> On 14-04-22, 14:45, Viresh Kumar wrote: Hello, We verified our hypervisor-agnostic Rust based vhost-user backends with Qemu based setup earlier, and there was growing concern if they were truly hypervisor-agnostic. In order to prove that, we decided to give it a try with Xen, a type-1 bare-metal hypervisor. We are happy to announce that we were able to make progress on that front and have a working setup where we can test our existing Rust based backends, like I2C, GPIO, RNG (though only I2C is tested as of now) over Xen. Key components: -- - Xen: https://github.com/vireshk/xen Xen requires MMIO and device specific support in order to populate the required devices at the guest. This tree contains four patches on the top of mainline Xen, two from Oleksandr (mmio/disk) and two from me (I2C). - libxen-sys: https://github.com/vireshk/libxen-sys We currently depend on the userspace tools/libraries provided by Xen, like xendevicemodel, xenevtchn, xenforeignmemory, etc. This crates provides Rust wrappers over those calls, generated automatically with help of bindgen utility in Rust, that allow us to use the installed Xen libraries. Though we plan to replace this with Rust based "oxerun" (find below) in longer run. - oxerun (WIP): https://gitlab.com/mathieupoirier/oxerun/-/tree/xen-ioctls This is Rust based implementations for Ioctl and hypercalls to Xen. This is WIP and should eventually replace "libxen-sys" crate entirely (which are C based implementation of the same). >> I'm curious to learn why there is a need to replace libxen-sys with the >> pure Rust implementation. Those libraries (xendevicemodel, xenevtchn, >> xenforeignmemory) are very stable and battle tested. Their interfaces >> are stable. > > Very easy. The library APIs are mess even if they are technically > stable, and violate various commonly-agreed rules of being a libary such > as not messing with stdout/stderr behind the applications back, and > everything gets more simple when you remove an unnecessary level of C > indirection. >>> >>> You don't have to use the stdio logger FWIW. I don't disagree things can >>> be simpler though. >> >> Not directly related to this use case but the Rust API can also be >> built to make direct HYP calls which will be useful for building Rust >> based unikernels that need to interact with Xen. For example for a >> dom0less system running a very minimal heartbeat/healthcheck monitor >> written in pure rust. >> > > I think this is a strong reason for not using existing C libraries. It > would be nice if the APIs can work with no_std. This was the goal I had with the way I structured the xen-sys crate. > >> We would also like to explore unikernel virtio backends but I suspect >> currently the rest of the rust-vmm virtio bits assume a degree of POSIX >> like userspace to set things up. > Same area I had an interest in. As well. I played with a xenstore implementation in a unikernel as well. Some of the code was published but unfortunately the actual functional bits were not. — Doug
Re: [PATCH for-4.15] automation: allow doing hypervisor only builds
On 3/3/21 8:33 AM, Roger Pau Monne wrote: For things like randconfig there's no need to do a full Xen build, a hypervisor build only will be much faster and will achieve the same level of testing, as randconfig only changes the hypervisor build options. Signed-off-by: Roger Pau Monné --- Acked-by: Doug Goldstein
Re: [PATCH] kconfig: ensure strndup() declaration is visible
On 1/11/21 8:42 AM, Jan Beulich wrote:
Its guard was updated such that it is visible by default when POSIX 2008
was adopted by glibc. It's not visible by default on older glibc.
Fixes: f80fe2b34f08 ("xen: Update Kconfig to Linux v5.4")
Signed-off-by: Jan Beulich
--- a/xen/tools/kconfig/parser.y
+++ b/xen/tools/kconfig/parser.y
@@ -4,6 +4,7 @@
*/
%{
+#define _GNU_SOURCE
#include
#include
#include
Ack-by: Doug Goldstein
OpenPGP_0xE15EE761499A935E.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] ci: drop building on CentOS 6
On 11/18/20 10:39 AM, Andrew Cooper wrote: > On 18/11/2020 16:27, Doug Goldstein wrote: >> CentOS 6 is no longer supported by upstream so we cannot test against it >> for future Xen releases. >> >> Signed-off-by: Doug Goldstein >> --- >> CC: Andrew Cooper >> CC: George Dunlap >> CC: Ian Jackson >> CC: Jan Beulich >> CC: Julien Grall >> CC: Stefano Stabellini >> CC: Wei Liu > > Acked-by: Andrew Cooper > > Do we want to drop the dockerfiles as well? We probably also want to > drop one line from containerise as well. > > I can fix on commit if you're happy with this. > > ~Andrew > Yes. That would make sense and should have included that. Thank you.
Re: [PATCH v1 2/4] automation/: add Ubuntu:focal container
On 11/17/20 12:24 PM, Edwin Török wrote: > Signed-off-by: Edwin Török Looks good. Do you have permissions to push the container or do you need me to? Acked-by: Doug Goldstein
Re: [PATCH v1 1/4] automation/scripts/containerize: fix DOCKER_CMD=podman
On 11/17/20 12:24 PM, Edwin Török wrote: > On CentOS 8 with SELinux containerize doesn't work at all: > > Make sure that the source code and SSH agent directories are passed on > with SELinux relabeling enabled. > (`-security-opt label=disabled` would be another option) > > Signed-off-by: Edwin Török Looks reasonable. Acked-by: Doug Goldstein
[PATCH] ci: drop building on CentOS 6
CentOS 6 is no longer supported by upstream so we cannot test against it for future Xen releases. Signed-off-by: Doug Goldstein --- CC: Andrew Cooper CC: George Dunlap CC: Ian Jackson CC: Jan Beulich CC: Julien Grall CC: Stefano Stabellini CC: Wei Liu --- automation/gitlab-ci/build.yaml | 10 -- 1 file changed, 10 deletions(-) diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml index 1e61d30c85..4bd1cfc1c0 100644 --- a/automation/gitlab-ci/build.yaml +++ b/automation/gitlab-ci/build.yaml @@ -176,16 +176,6 @@ centos-7-gcc-debug: variables: CONTAINER: centos:7 -centos-6-gcc: - extends: .gcc-x86-64-build - variables: -CONTAINER: centos:6 - -centos-6-gcc-debug: - extends: .gcc-x86-64-build-debug - variables: -CONTAINER: centos:6 - debian-jessie-clang: extends: .clang-x86-64-build variables: -- 2.21.0 (Apple Git-122)
Re: [Xen-devel] [PATCH] automation: document vsyscall=emulate for old glibc
On 2/25/20 6:10 AM, Wei Liu wrote: > Signed-off-by: Wei Liu Acked-by: Doug Goldstein Do I need to make this tweak on the current runners? pEpkey.asc Description: application/pgp-keys ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH 1/3] automation: Only build QEMU if Python >= 3.5
On 1/20/20 5:50 AM, Anthony PERARD wrote: Recent version of QEMU will not build anymore if Python < 3.5. That is, QEMU 4.3 not released yet. That check would also prevent the GitLab CI from building QEMU if python3 binary isn't present. Signed-off-by: Anthony PERARD Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH 2/3] automation: updating container to have python3-config binary
On 1/20/20 5:50 AM, Anthony PERARD wrote: Those containers have already been updated in GitLab: - debian/stretch - debian/stretch-i386 - debian/unstable - debian/unstable-i386 - fedora/29 - suse/opensuse-leap - ubuntu/bionic - ubuntu/trusty - ubuntu/xenial The container debian:unstable-arm64v8 haven't been changed. Signed-off-by: Anthony PERARD Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests
On 1/11/20 3:02 AM, George Dunlap wrote: On Jan 11, 2020, at 4:02 AM, Doug Goldstein wrote: On 1/10/20 4:37 AM, Sergey Dyasli wrote: Hide the following information that can help identify the running Xen binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset. Add explicit cases for XENVER_commandline and XENVER_build_id as well. Introduce xsm_filter_denied() to hvmloader to remove "" string from guest's DMI tables that otherwise would be shown in tools like dmidecode. Signed-off-by: Sergey Dyasli --- v1 --> v2: - Added xsm_filter_denied() to hvmloader instead of modifying xen_deny() So 100% this version of the patch won't fly with the various downstreams that run the v1 of this patch. Those various consumers will stick with v1. If the goal of this is to reduce the burden of the downstreams and their customers to carry a patch against Xen then I wouldn't even bother with this version. If the goal is to come up with a solution that works for everyone, it would be helpful if you said *why* “various consumers” would find this patch unacceptable; and also what they might think about the alternate solutions proposed (and why). -George I'd be happy if we had a Kconfig option behind what the string is. Give me a blank as an option but default it to whatever string like "" that you'd like. Every shipping Xen distro I've worked on has had its own v1 variant of the patch and none of them authored by me. Xen is a bit unique in the software world as most pieces of software aren't run in an "adversarial" environment. Look at any multi-tenant cloud provider. There's continually bad actors that are creating VMs and probing your system configurations and attempting to build a fingerprinting technique to identify exploitable systems vs not exploitable systems. Many security issues are dropped on providers without adequate time to patch all the systems prior to a disclosure. Look at systems like OpenXT, SecureView and Qubes where the users of these systems don't necessarily update to the latest fix immediately. Now I know someone is going to read this and say "Look at Doug and him advocating for security through obscurity". But that's simply not the case. The point is anything that can be used to fingerprint a system easily and target an attack against that system is very different from saying my interfaces are secure because I don't publish the spec. When attackers are forced to probe a system it results in an opportunity to identity that behavior and take action. I'll just end saying that stripping information in dom0 from the domU has not been considered acceptable in various circles because it changes the stance from "It is not possible to leak this data" to "This data cannot leak if action X happens correctly". Which then requires tests and documentation to show that it is not possible to leak. Ultimately my point is if the goal of this patch is to upstream a patch that's carried by various downstreams, why not actually listen to what caused them to write the patch? In your other email you talk about developers being concerned about tracing the build of Xen or if they built it wrong. In the cases I'm talking about there's literally 0 concern for that. The build of Xen is captured very well as an artifact of the deployment and certification of that build. The developers of that build of Xen know exactly the revision that the specific system is using and when they receive information they can go right to that revision. -- Doug ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests
On 1/10/20 4:37 AM, Sergey Dyasli wrote: Hide the following information that can help identify the running Xen binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset. Add explicit cases for XENVER_commandline and XENVER_build_id as well. Introduce xsm_filter_denied() to hvmloader to remove "" string from guest's DMI tables that otherwise would be shown in tools like dmidecode. Signed-off-by: Sergey Dyasli --- v1 --> v2: - Added xsm_filter_denied() to hvmloader instead of modifying xen_deny() So 100% this version of the patch won't fly with the various downstreams that run the v1 of this patch. Those various consumers will stick with v1. If the goal of this is to reduce the burden of the downstreams and their customers to carry a patch against Xen then I wouldn't even bother with this version. -- Doug ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests
On 1/10/20 9:28 AM, George Dunlap wrote: On 1/10/20 11:02 AM, Andrew Cooper wrote: On 10/01/2020 10:37, Sergey Dyasli wrote: Hide the following information that can help identify the running Xen binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset. Add explicit cases for XENVER_commandline and XENVER_build_id as well. Introduce xsm_filter_denied() to hvmloader to remove "" string from guest's DMI tables that otherwise would be shown in tools like dmidecode. Signed-off-by: Sergey Dyasli --- v1 --> v2: - Added xsm_filter_denied() to hvmloader instead of modifying xen_deny() - Made behaviour the same for both Release and Debug builds - XENVER_capabilities is no longer hided CC: Andrew Cooper CC: George Dunlap CC: Ian Jackson CC: Jan Beulich CC: Julien Grall CC: Konrad Rzeszutek Wilk CC: Stefano Stabellini CC: Wei Liu CC: Daniel De Graaf I realise there are arguments over how to fix this, but we (the Xen community) have already f*cked up once here, and this is doing so a second time. Nack. Fixing it anywhere other than Xen is simply not appropriate. The reason for this (which ought to be obvious, but I guess only to those who actually do customer support) is basic human physiology. "denied" means something has gone wrong. It scares people, and causes them to seek help to change fix whatever is broken. This seems like a reasonable argument that "" causes issues. But that doesn't change the fact that "" also causes issues. I'd be curious to hear the case where the empty string causes issues. -- Doug ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 0/2] x86: clank build check adjustments
On 11/15/19 8:45 AM, Roger Pau Monné wrote: On Fri, Nov 15, 2019 at 11:43:21AM +0100, Jan Beulich wrote: 1: fix clang .macro retention check 2: clang: move and fix .skip check For both: Tested-by: Roger Pau Monné [On FreeBSD and Debian 9.5] Reviewed-by: Roger Pau Monné Note there's a typo in this email's subject (clank v clang). Also, if possible, could both patches have the same prefix? (x86/clang) Roger, Do we need to make changes to the containers that build the tree? These patches broken the clang builds in CI as can be seen here: https://gitlab.com/xen-project/xen/-/jobs/365246563#L2371 -- Doug ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V2] kdd.c: Add support for initial handshake in KD protocol for Win 7, 8 and 10 (64 bit)
On 11/13/19 10:55 PM, Julian Tuminaro wrote: From: Julian Tuminaro and Jenish Rakholiya Current implementation of find_os is based on the hard-coded values for different Windows version. It uses the value for get the address to start looking for DOS header in the given specified range. However, this is not scalable to all version of Windows as it will require us to keep adding new entries and also due to KASLR, chances of not hitting the PE header is significant. We implement a way for 64-bit systems to use IDT entry to get a valid exception/interrupt handler and then move back into the memory to find the valid DOS header. Since IDT entries are protected by PatchGuard, we think our assumption that IDT entries will not be corrupted is valid for our purpose. Once we have the image base, we search for the DBGKD_GET_VERSION64 structure type in .data section to get information required for handshake. Currently, this is a work in progress feature and current patch only supports the handshake and memory read/write on 64-bit systems. NOTE: This is the Updated version of the previous patch submitted NOTE: This has currently been only tested when debugging was not enabled on the guest Windows. Signed-off-by: Jenish Rakholiya Signed-off-by: Julian Tuminaro --- This commit has broken the build of the staging tree. For a full log see: https://gitlab.com/xen-project/xen/-/jobs/365398313#L5184 But the relevant bit is likely: || |gcc -m32 -march=i686 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .kdd-xen.o.d -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -I/builds/xen-project/xen/tools/debugger/kdd/../../../tools/libxc/include -I/builds/xen-project/xen/tools/debugger/kdd/../../../tools/libs/toollog/include -I/builds/xen-project/xen/tools/debugger/kdd/../../../tools/include -I/builds/xen-project/xen/tools/debugger/kdd/../../../tools/libs/foreignmemory/include -I/builds/xen-project/xen/tools/debugger/kdd/../../../tools/include -I/builds/xen-project/xen/tools/debugger/kdd/../../../tools/libs/devicemodel/include -I/builds/xen-project/xen/tools/debugger/kdd/../../../tools/include -I/builds/xen-project/xen/tools/debugger/kdd/../../../tools/include -D__XEN_TOOLS__ -DXC_WANT_COMPAT_MAP_FOREIGN_API -c -o kdd-xen.o kdd-xen.c | | In file included from kdd.c:53:0: kdd.c: In function 'get_os_info_64': kdd.c:616:35: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] KDD_LOG(s, "idt0 addr: %p\n", (void *)idt0_addr); | ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] current staging x86 hypervisor build fails with clang
Hello, The following build failure happens when using clang to build the hypervisor. This is a default config. make -f /builds/xen-project/xen/xen/Rules.mk /builds/xen-project/xen/xen/.xen.efi.0r.o /builds/xen-project/xen/xen/.xen.efi.0s.o grep -v 'DEFINE_XEN_GUEST_HANDLE(long)' public/nmi.h | \ python /builds/xen-project/xen/tools/firmware/xen-dir/xen-root/xen/tools/compat-build-source.py >compat/nmi.c.new make[4]: Entering directory '/builds/xen-project/xen/xen/arch/x86' Duplicate symbol 'asid.c#get_cpu_info' (82d08030c1b0 != 82d0802e8eb0) Duplicate symbol 'asid.c#get_cpu_info_from_stack' (82d08030c1e0 != 82d0802e8fe0) Duplicate symbol 'ats.c#__list_add' (82d080268cd0 != 82d080261770) Duplicate symbol 'boot.c#constant_test_bit' (82d080432330 != 82d080408bf0) Duplicate symbol 'common.c#clear_bit' (82d08033d030 != 82d0802db210) Duplicate symbol 'common.c#constant_test_bit' (82d08033cf10 != 82d0802da260) Duplicate symbol 'common.c#cpumask_check' (82d0803427d0 != 82d0802db220) Duplicate symbol 'common.c#get_cpu_info' (82d08033c150 != 82d0802da280) Duplicate symbol 'common.c#get_cpu_info_from_stack' (82d080342c20 != 82d0802db310) Duplicate symbol 'common.c#test_and_set_bit' (82d08033ce30 != 82d0802db250) Duplicate symbol 'common.c#variable_clear_bit' (82d0803427e0 != 82d0802da240) Duplicate symbol 'compat.c#get_cpu_info' (82d08026fad0 != 82d0802004b0) Duplicate symbol 'compat.c#get_cpu_info_from_stack' (82d08026fc00 != 82d0802010e0) Duplicate symbol 'cpu_idle.c#get_cpu_info' (82d08036b690 != 82d0802d48a0) Duplicate symbol 'cpu_idle.c#get_cpu_info_from_stack' (82d08036b970 != 82d0802d71b0) Duplicate symbol 'cpufreq.c#_xmalloc_array' (82d0802d8740 != 82d080250520) Duplicate symbol 'cpufreq.c#bitmap_empty' (82d0802d85b0 != 82d080250680) Duplicate symbol 'cpufreq.c#bitmap_weight' (82d0802d85a0 != 82d0802506b0) Duplicate symbol 'cpufreq.c#cpumask_check' (82d0802d83a0 != 82d0802506a0) Duplicate symbol 'cpufreq.c#cpumask_empty' (82d0802d84e0 != 82d080250030) Duplicate symbol 'cpufreq.c#cpumask_first' (82d0802d8330 != 82d08024ff90) Duplicate symbol 'cpufreq.c#cpumask_test_cpu' (82d0802d7c50 != 82d08024fb40) Duplicate symbol 'cpufreq.c#cpumask_weight' (82d0802d8560 != 82d08024ffe0) Duplicate symbol 'cpufreq.c#get_cpu_info' (82d0802d7c80 != 82d080250540) Duplicate symbol 'cpufreq.c#get_cpu_info' (82d08036bb10 != 82d0802d7c80) Duplicate symbol 'cpufreq.c#get_cpu_info_from_stack' (82d0802d88f0 != 82d080250660) Duplicate symbol 'cpufreq.c#get_cpu_info_from_stack' (82d08036bb20 != 82d0802d88f0) Duplicate symbol 'cpufreq.c#variable_test_bit' (82d0802d8900 != 82d0802506d0) Duplicate symbol 'cpuid.c#array_index_mask_nospec' (82d08026f9b0 != 82d08026cfb0) Duplicate symbol 'cpuid.c#get_cpu_info' (82d08026f9d0 != 82d08026cfa0) Duplicate symbol 'cpuid.c#get_cpu_info_from_stack' (82d08026fa30 != 82d08026cfd0) Duplicate symbol 'cpuid.c#zero_leaves' (82d08026f0d0 != 82d08026c6d0) Duplicate symbol 'dom0_build.c#__maddr_to_virt' (82d08043a460 != 82d080437c40) Duplicate symbol 'dom0_build.c#_mfn' (82d080438a30 != 82d080437bf0) Duplicate symbol 'dom0_build.c#clear_bit' (82d08043b010 != 82d080437c20) Duplicate symbol 'dom0_build.c#constant_test_bit' (82d08043a3a0 != 82d080437f20) Duplicate symbol 'dom0_build.c#elf_set_vcpu' (82d08043a8a0 != 82d080437c30) Duplicate symbol 'dom0_build.c#get_order_from_pages' (82d08043a410 != 82d080438130) Duplicate symbol 'dom0_build.c#mfn_x' (82d080438a20 != 82d080437f10) Duplicate symbol 'dom0_build.c#pdx_to_pfn' (82d08043a3f0 != 82d080438160) Duplicate symbol 'dom0_build.c#pfn_to_pdx' (82d080438a00 != 82d080437ca0) Duplicate symbol 'dom0_build.c#set_bit' (82d08043dff0 != 82d08043a3c0) Duplicate symbol 'domain.c#__rdgsbase' (82d080362ea0 != 82d0802789f0) Duplicate symbol 'domain.c#__virt_to_maddr' (82d080362ff0 != 82d080273e10) Duplicate symbol 'domain.c#_gfn' (82d080274a20 != 82d0802099b0) Duplicate symbol 'domain.c#_gfn' (82d0802eab70 != 82d080274a20) Duplicate symbol 'domain.c#_mfn' (82d080273aa0 != 82d080208d10) Duplicate symbol 'domain.c#_mfn' (82d0802eab00 != 82d080273aa0) Duplicate symbol 'domain.c#_mfn' (82d0803630e0 != 82d0802eab00) Duplicate symbol 'domain.c#_xzalloc_array' (82d080362b50 != 82d080207690) Duplicate symbol 'domain.c#atomic_read' (82d080275f10 != 82d080209960) Duplicate symbol 'domain.c#bitmap_empty' (82d080278660 != 82d080209a10) Duplicate symbol 'domain.c#clear_bit' (82d080276070 != 82d080208ae0) Duplicate symbol 'domain.c#constant_test_bit' (82d080274600 != 82d080209600) Duplicate symbol 'domain.c#constant_test_bit'
Re: [Xen-devel] Status of 4.13
On 11/21/19 12:05 AM, Jürgen Groß wrote: Where do we stand with Xen 4.13 regarding blockers and related patches? 1. Currently the default "make install" fails with errors in tools/tests/x86_emulator if you don't have a new enough GCC. Causing failures on distros that are considered still supported based on README. 2. The hypervisor currently fails to build with clang using versions that READM says are supported no matter the configuration. -- Doug ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] tools/tests/x86_emulator causes build failures with older but supported compilers
On 11/25/19 4:44 AM, Jan Beulich wrote:
On 23.11.2019 19:00, Doug Goldstein wrote:
Per README, GCC 4.1.2 should lead to a successful default "make install"
per INSTALL. Currently this is failing due to tools/tests/x86_emulator
being in the default path and requiring a compiler with AVX. GCC 4.4.7
on CentOS 6 does not have this leading to a failure to build.
1265 make[5]: Entering directory `/builds/xen-project/xen/tools/tests'
1266 make -C x86_emulator install
1267 cc1: error: unrecognized command line option "-mavx2"
1268 cc1: error: unrecognized command line option "-mavx512f"
1269 cc1: error: unrecognized command line option "-mavx512bw"
1270 cc1: error: unrecognized command line option "-mavx512dq"
1271 cc1: error: unrecognized command line option "-mavx512er"
1272 cc1: error: unrecognized command line option "-mavx512vbmi"
1273 /tmp/ccMkLpTV.s: Assembler messages:
1274 /tmp/ccMkLpTV.s:3: Error: junk at end of line, first unrecognized
character is `{'
These are errors, yes, but ...
1275 make[6]: Entering directory
`/builds/xen-project/xen/tools/tests/x86_emulator'
1276 Makefile:116: Test harness not built, use newer compiler than "gcc"
(version 4.4.7) and an "{evex}" capable assembler
1277 make[6]: Nothing to be done for `install'.
... there's no build failure here afaics, and this is the intended
way of how things are to work.
The tree is intended to build with a default "make install" with a
supported set of tools from README. This is part of the conversations
we've had in the past about what should be treated as proper and it was
universally agreed.
2. Fix the default build to work with older GCC versions.
Not a reasonable option either, as it would be cluttering the harness
with all sorts of #ifdef-s or abstracting wrappers, making it even
more difficult to make changes to it.
What was considered in the past was to skip building of tests/ as a
whole in non-debug builds; don't know what has come of this. It is
probably telling enough that the bottom of ./Config.mk reads like this:
# Short answer -- do not enable this unless you know what you are
# doing and are prepared for some pain.
CONFIG_TESTS ?= y
Then this is what the default of the tree should be.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] tools/tests/x86_emulator causes build failures with older but supported compilers
Hello,
Per README, GCC 4.1.2 should lead to a successful default "make install"
per INSTALL. Currently this is failing due to tools/tests/x86_emulator
being in the default path and requiring a compiler with AVX. GCC 4.4.7
on CentOS 6 does not have this leading to a failure to build.
1265 make[5]: Entering directory `/builds/xen-project/xen/tools/tests'
1266 make -C x86_emulator install
1267 cc1: error: unrecognized command line option "-mavx2"
1268 cc1: error: unrecognized command line option "-mavx512f"
1269 cc1: error: unrecognized command line option "-mavx512bw"
1270 cc1: error: unrecognized command line option "-mavx512dq"
1271 cc1: error: unrecognized command line option "-mavx512er"
1272 cc1: error: unrecognized command line option "-mavx512vbmi"
1273 /tmp/ccMkLpTV.s: Assembler messages:
1274 /tmp/ccMkLpTV.s:3: Error: junk at end of line, first unrecognized
character is `{'
1275 make[6]: Entering directory
`/builds/xen-project/xen/tools/tests/x86_emulator'
1276 Makefile:116: Test harness not built, use newer compiler than "gcc"
(version 4.4.7) and an "{evex}" capable assembler
1277 make[6]: Nothing to be done for `install'.
Full log here: https://gitlab.com/xen-project/xen/-/jobs/358852978#L1266
We have 2 options for the next release:
1. Bump the minimum GCC requirement for the tree and drop any support
for any distro not matching that requirement.
2. Fix the default build to work with older GCC versions.
Thanks.
--
Doug
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/3] automation: add openSUSE Tumbleweed CI image
On 7/31/19 11:58 AM, Dario Faggioli wrote: openSUSE comes in two flavours: Leap, which is non-rolling, and released annualy, and Tumbleweed, which is rolling. Reasons why it makes sense to have both (despite both being openSUSE, package lists in dockerfiles being quite similar, etc) are: - Leap share a lot with SUSE Linux Enterprise. So, regressions on Leap, not only means regressions for all openSUSE Leap users, but also helps prevent/catch regressions on SLE; - Tumbleweed often has the most bleeding-edge software, so it will help us prevent/catch regressions with newly released versions of libraries, compilers, etc (e.g., at the time of writing this commit, some build issues, with GCC9, where discovered while trying to build in a Tumbleweed image). Note that, considering the rolling nature of Tumbleweed, the container would need to be rebuilt (e.g., periodically), even if the docker file does not change. Signed-off-by: Dario Faggioli Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/3] automation: build in openSUSE Tumbleweed
On 7/31/19 11:58 AM, Dario Faggioli wrote: Signed-off-by: Dario Faggioli Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/3] automation: try to keep openSUSE Leap image a little smaller
On 7/31/19 11:58 AM, Dario Faggioli wrote: Using `--no-recommends` when updating or installing commands should prevent non strictly necessary packages to be installed. doing a `clean -a` after installing all the packages, should, in theory, free more space (as opposed to using just `clean`). Signed-off-by: Dario Faggioli Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] automation: add info about container pushes
To be able to push a container, users must have access and have logged into the container registry. The docs did not explain this fully so this documents the steps better. Signed-off-by: Doug Goldstein --- automation/build/README.md | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/automation/build/README.md b/automation/build/README.md index d8c8a18e33..476f82cf45 100644 --- a/automation/build/README.md +++ b/automation/build/README.md @@ -66,6 +66,10 @@ There is a makefile to make this process easier. You should be able to run `make DISTRO/VERSION` to have Docker build the container for you. If you define the `PUSH` environment variable when running the former `make` command, it will push the container to the [registry] if -you have access to do so. +you have access to do so and have your Docker logged into the registry. + +To login you must run `docker login registry.gitlab.com`. For more +information see the [registry help]. [registry]: https://gitlab.com/xen-project/xen/container_registry +[registry help]: https://gitlab.com/help/user/project/container_registry -- 2.20.1 (Apple Git-117) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] ci: install C++ in opensuse-leap CI container
On 8/2/19 9:37 AM, Dario Faggioli wrote: On Fri, 2019-08-02 at 13:11 +0100, Andrew Cooper wrote: On 02/08/2019 13:00, Dario Faggioli wrote: On Mon, 2019-07-29 at 12:18 -0500, Doug Goldstein wrote: Will you be pushing the rebuilt container or do you need me to do that? So, I guess someone else, with enough rights, would have to do that. Or am I missing some auth step or aomething? You need to do a docker login to the registry. See https://gitlab.com/help/user/project/container_registry Ah, that's what I was missing! I'll submit a patch to update the docs to make this clear. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] ci: install C++ in opensuse-leap CI container
On 7/26/19 5:03 AM, Dario Faggioli wrote: The openSUSE Leap container image, built after opensuse-leap.dockerfile was missing the gcc-c++, which is necessary, e.g., for building OVMF. Add it. Signed-off-by: Dario Faggioli --- Cc: Doug Goldstein --- Acked-by: Doug Goldstein Will you be pushing the rebuilt container or do you need me to do that? ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Criteria / validation proposal: drop Xen
On 7/8/19 11:11 AM, Adam Williamson wrote: On Tue, 2019-05-21 at 11:14 -0700, Adam Williamson wrote: "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen." and change the 'milestone' for the test case - https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt - from Final to Optional. Thoughts? Comments? Thanks! I would prefer for it to remain as it is. This is only practical if it's going to be tested, and tested regularly - not *only* on the final release candidate, right before we sign off on the release. It needs to be tested regularly throughout the release cycle, on the composes that are "nominated for testing". Would the proposal above work for you? I think it satisfies what you are looking for. We would also have someone who monitors these test results pro-actively. In theory, yeah, but given the history here I'm somewhat sceptical. I'd also say we still haven't really got a convincing case for why we should continue to block the release (at least in theory) on Fedora working in Xen when we don't block on any other virt stack apart from our 'official' one, and we don't block on all sorts of other stuff we'd "like to have working" either. Regardless of the testing issues, I'd like to see that too if we're going to keep blocking on Xen... So, this died here. As things stand: I proposed removing the Xen criterion, Lars opposed, we discussed the testing situation a bit, and I said overall I'm still inclined to remove the criterion because there's no clear justification for it for Fedora any more. Xen working (or rather, Fedora working on Xen) is just not a key requirement for Fedora at present, AFAICS. It's worth noting that at least part of the justification for the criterion in the first place was that Amazon was using Xen for EC2, but that is no longer the case, most if not all EC2 instance types no longer use Xen. Another consideration is that there was a time when KVM was still pretty new stuff and VirtualBox was not as popular as it is now, and Xen was still widely used for general hobbyist virtualization purposes; I don't believe that's really the case any more. So I'll just point out this is false. Amazon very much uses Xen still and is investing in Xen still. In fact I'm writing this email from the XenSummit where Amazon is currently discussing their future development efforts for the Xen Project. -- Doug ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] XSA-300 Wording
Could we look at updating the wording of XSA-300 to make things a bit more clear. I don't have exact wording suggestions but roughly some of the questions I've fielded are: 1. Impact should make it clear there are two issues here. So its really "and/or". Or a bulleted list. 2. Vulnerable Systems. "All versions of Linux are vulnerable" does this apply to guests. Only reason that was asked is because the next sentence goes on to discuss dom0. Are people that didn't pass a "dom0_mem=" on a PV dom0 vulnerable or not? 3. Mitigation. Is there no mitigation for PVH dom0's? There's some handwaving around "sufficiently large". Large is subjective to folks. If I operate with machines with 8GB of RAM day in and day out then my definition of "large" is different from someone that operates on machines with 256GB of RAM day in and day out. 4. Resolution. There's two issues here (as the Impact should make clear). Identify that the patch handles issue "#1" while issue "#2" is not fixed yet. I hope this is a reasonable request. -- Doug ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/Kconfig: Fix -Wformat-security when compiling with Clang
On Wed, Jun 26, 2019 at 06:36:15PM +0100, Andrew Cooper wrote:
> Clang observes:
>
> tools/kconfig/conf.c:77:10:
> warning: format string is not a string literal (potentially insecure)
> [-Wformat-security]
> printf(_("aborted!\n\n"));
>^
>
> And it is absolutely correct. gettext() can easily return a string with a %
> in.
>
> This could be fixed by switching to using printf("%s", _(...)), or by
> switching to puts() (as there is no formatting going on), but the better
> option is follow Linux and remove localisation support.
>
> Linux changeset: 694c49a7c01cc87194be40cb26404b58b68c291c
> Author: Sam Ravnborg
> Date: Tue May 22 20:36:12 2018
>
> kconfig: drop localization support
>
> The localization support is broken and appears unused.
> There is no google hits on the update-po-config target.
> And there is no recent (5 years) activity related to the localization.
>
> So lets just drop this as it is no longer used.
>
> Suggested-by: Ulf Magnusson
> Suggested-by: Masahiro Yamada
> Signed-off-by: Sam Ravnborg
> Signed-off-by: Masahiro Yamada
>
> [Ported to Xen]
> Reported-by: Roger Pau Monné
> Signed-off-by: Andrew Cooper
I haven't built this locally but overall I think this is a good backport
to do. In the past there were a lot of concerns about the size of the
Kconfig code base that we were bringing into the tree and some of the
functionality that seemed less than necessary. The approach was taken to
always backport from Linux to ease the maintenance burden for Xen but a
backport like this seems like it achieves both goals.
Acked-by: Doug Goldstein
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation: Fix CI with the fedora container
On Tue, Jun 11, 2019 at 11:56:36AM +0100, Andrew Cooper wrote: > A recent rebuild of the CI contaniers switched from Fedora 29 to 30 because > the dockerfile is targetting latest. > > Unfortunately, the version of iPXE in master doesn't build with the default > GCC in Fedora 30, which is blocking all CI activity. > > Switch from latest to an explicit version, to avoid future breakage. > > Signed-off-by: Andrew Cooper Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4] automation: add clang and lld 8 tests to gitlab
On Mon, Jun 10, 2019 at 06:32:46PM +0200, Roger Pau Monne wrote: > Using clang and lld 8 requires installing the packages from the > official llvm apt repositories, so modify the Debian Docker files for > stretch and unstable to add the llvm repo and install clang and lld > from it. > > Also add some jobs to test building Xen with clang 8 and lld. > > Signed-off-by: Roger Pau Monné > Acked-by: Andrew Cooper Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] gitlab-ci: allow specifying base and tip in build test
On Tue, Apr 16, 2019 at 08:21:39AM +0100, Wei Liu wrote: > We will soon provide this new capability to humans and automated > systems. > > The default behaviour is retained: tip and base are passed by Gitlab > CI. > > Signed-off-by: Wei Liu Swore I replied to this already. I apologize. Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] gitlab-ci: avoid deleting build-each-commit-gcc.log
On Tue, May 07, 2019 at 05:11:01PM +0100, Wei Liu wrote: > 072a96c4901 used `git clean -ffdx` which caused the log to be deleted. > > Generate the log in the parent directory then move it back. > > Signed-off-by: Wei Liu Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen project CI systems and committer workflow
On Thu, Apr 18, 2019 at 02:59:17PM +0100, Andrew Cooper wrote: > On 18/04/2019 13:31, Wei Liu wrote: > > Hi all > > > > We now have Gitlab CI as a complementary system to Osstest and have planned > > to > > add bots. It's high time we think about how we integrate them and how it may > > improve our workflow. > > > > ## Requirements > > > > 1. We want to have light weight build tests before a patch series is > > reviewed > > or committed. > > > > 2. We don't want to push broken patches to central repository such that > > everyone is blocked. > > > > 3. We don't want to significantly change committer workflow. > > > > Requirement 2 means that our current branching model will need to be > > changed. > > Details will follow. > > While everything presented here is fine to do as a matter of policy, the > committers still need to retain the ability to actually push directly to > the staging branches on xen.git > > The security team needs to be able to make embargoed content appear at > the point of public disclosure. The security team already takes > responsibility for all testing of this content before the public embargo > point, and this policy will need to continue. > > ~Andrew What about the ability to push a branch to the CI loop with the highest priority so that its picked up immediately? There has been more than one XSA where the patches provided in the emails don't apply cleanly or don't build so it does seem valuable to still run the CI loop. -- Doug ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen project CI systems and committer workflow
On Thu, Apr 18, 2019 at 02:21:44PM +0100, Ian Jackson wrote: > > > Gitlab CI doesn't have a self pushgate. If it is broken by accident Osstest > > will be blocked. > > Could we plan some kind of procedural or robotic workaround ? So my thoughts around this are on priority values. Admittedly it could use some refinement but roughly speaking if someone pushed a series that broke osstest we could have a fix-up series/patch where it was acked and it was given a priority weight higher than any other series. This would cause the GitLab CI loop to test that series and get that pushed above all others. Similarly to avoid bogging down testing for small changes like docs/comments/etc having a "rollup" tag which would have GitLab CI create a series from all things currently labeled "rollup" as push them as a whole. -- Doug ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen project CI systems and committer workflow
On Thu, Apr 18, 2019 at 01:32:52PM +0100, Wei Liu wrote: > Cc Anthony as well. Forgot to do that. Sorry. > > On Thu, Apr 18, 2019 at 01:31:59PM +0100, Wei Liu wrote: > > Hi all > > > > We now have Gitlab CI as a complementary system to Osstest and have planned > > to > > add bots. It's high time we think about how we integrate them and how it may > > improve our workflow. FWIW, I planned on submitting on a talk on this. I plan on giving an overview to everyone at the summit and allowing for discussion. Potentially even hosting a BoF if there is interest in discussing this further. -- Doug ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/3] gitlab-ci: add fedora gcc build jobs
On Thu, Apr 04, 2019 at 12:23:02PM +0100, Wei Liu wrote: > Although the image comes with clang, clang builds don't work yet. > > Signed-off-by: Wei Liu Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] automation: Add Arch Linux container and build jobs
> On Apr 3, 2019, at 12:33 PM, Anthony PERARD wrote: > > One particularity of Arch Linux, /usr/bin/python is python3. > > Signed-off-by: Anthony PERARD Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] automation: enable building rombios with clang
>>> On Mar 15, 2019, at 8:34 AM, Wei Liu wrote:
>>>
>>>> On Sat, Aug 25, 2018 at 10:01:38PM -0500, Doug Goldstein wrote:
>>>>> On Fri, Aug 24, 2018 at 04:34:35PM +0100, Wei Liu wrote:
>>>>> On Fri, Aug 24, 2018 at 10:32:24AM -0500, Doug Goldstein wrote:
>>>>> On Fri, Aug 24, 2018 at 04:22:47PM +0100, Wei Liu wrote:
>>>>> Previously it is disabled because the embedded ipxe can't be built
>>>>> with clang. Now that ipxe is split out we can use --with-system-ipxe
>>>>> to work around the issue.
>>>>>
>>>>> Signed-off-by: Wei Liu
>>>>> ---
>>>>> +# iPXE cannot be built with clang
>>>>> +cfgargs+=("--with-system-ipxe=/usr/lib/ipxe/ipxe.pxe")
>>>>
>>>> Did we ever get all the containers updated with this file in place?
>>>
>>> No. I didn't. Do we care? Xen's build system doesn't check if that file
>>> exists. It merely puts the string into appropriate places.
>>>
>>> Wei.
>>
>> Well then that works for me. Just wondering if you've pushed a branch
>> with this and had GitLab run over it?
>
> I take that "that works for me" as an approval. :-)
>
> I will commit this patch shortly.
>
> Wei.
Yes. Apologies for not being explicit.
Acked-by: Doug Goldstein
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation: skip test stage for some branches
> On Dec 10, 2018, at 9:11 AM, Wei Liu wrote: > > We skipped build stage for those branches. We want to skip test state > for those branches too. > > Signed-off-by: Wei Liu Thanks for taking care of this. Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] automation: break .gitlab-yaml into smaller files
On Thu, Nov 22, 2018 at 03:49:03PM +, Wei Liu wrote: > Break out files for build jobs and test jobs. Keep the top level > .gitlab-ci.yaml small. > > Signed-off-by: Wei Liu Good idea with this split. Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] automation: add a qemu smoke test for clang build
On Thu, Nov 22, 2018 at 03:49:02PM +, Wei Liu wrote: > Also rename the old test to have -gcc suffix. > > Signed-off-by: Wei Liu Acked-by: Doug Goldstein Nice addition. Sorry for the delay. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation: git clean between builds
> On Nov 21, 2018, at 11:07 AM, Wei Liu wrote: > >> On Wed, Nov 21, 2018 at 10:51:55AM -0600, Doug Goldstein wrote: >> >>> On Nov 21, 2018, at 10:32 AM, Wei Liu wrote: >>> >>> Currently randconfig tests are more likely to fail than to succeed >>> because of a bug in xen's build system: symbols-dummy.o's dependency >>> is wrong, which causes it to not get rebuild between runs, which >>> eventually causes linking to fail. There may also be other corner >>> cases we haven't discovered. >>> >>> The fix is not straightforward. For now, make sure the tree is cleaned >>> properly between builds so we don't see random failures in Gitlab CI. >>> >>> Signed-off-by: Wei Liu >>> >> >> Sounds good as a fix for now to get us going. >> >> Acked-by: Doug Goldstein > > I think I will need to switch from git clean to make clean to avoid > wiping out all the artifacts. Does your ack still stand? > > Wei. Yes. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation: git clean between builds
> On Nov 21, 2018, at 10:32 AM, Wei Liu wrote: > > Currently randconfig tests are more likely to fail than to succeed > because of a bug in xen's build system: symbols-dummy.o's dependency > is wrong, which causes it to not get rebuild between runs, which > eventually causes linking to fail. There may also be other corner > cases we haven't discovered. > > The fix is not straightforward. For now, make sure the tree is cleaned > properly between builds so we don't see random failures in Gitlab CI. > > Signed-off-by: Wei Liu > Sounds good as a fix for now to get us going. Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/4] automation: add qemu smoke test
On Mon, Nov 19, 2018 at 09:31:02PM +, Wei Liu wrote:
> This patch introduces a new test stage into the pipeline and provides
> a simple QEMU based smoke test.
>
> Signed-off-by: Wei Liu
> ---
> .gitlab-ci.yml | 19 +++
> automation/scripts/qemu-smoke-x86-64.sh | 23 +++
> 2 files changed, 42 insertions(+)
> create mode 100755 automation/scripts/qemu-smoke-x86-64.sh
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index d11459b117..b9ccba6ab2 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -1,5 +1,6 @@
> stages:
>- build
> + - test
>
> .build-tmpl:
>stage: build
> @@ -379,3 +380,21 @@ debian-unstable-gcc-debug-arm64-randconfig:
>variables:
> CONTAINER: debian:unstable-arm64v8
> RANDCONFIG: y
> +
> +
> +# Test jobs
> +qemu-smoke-x86-64:
> + stage: test
> + image: registry.gitlab.com/xen-project/xen/${CONTAINER}
> + variables:
> +CONTAINER: debian:stretch
> + script:
> +- ./automation/scripts/qemu-smoke-x86-64.sh 2>&1 | tee
> qemu-smoke-x86-64.log
Do you want to capture this log in the artifacts below too?
> + artifacts:
> +paths:
> + - smoke.serial
> +when: always
> + dependencies:
> +- debian-stretch-gcc-debug
> + tags:
> +- x86_64
Just one quick question. If you do that can be fixed up at commit time
as well so I have no problem saying:
Acked-by: Doug Goldstein
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/4] automation: also specify xen binary as artifact on x86_64
On Mon, Nov 19, 2018 at 09:31:01PM +, Wei Liu wrote: > ... so that it can be passed on to test stage. > > Note that xen is only extracted for x86_64 build since others may not > have that. Use a directory to account for possibly different file > names on Arm. > > Signed-off-by: Wei Liu Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/4] automation: stash default config file for artifact extraction
On Mon, Nov 19, 2018 at 09:31:00PM +, Wei Liu wrote: > Signed-off-by: Wei Liu > --- > .gitlab-ci.yml | 2 +- > automation/scripts/build | 3 +++ > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > index 5678b552c4..28152e906d 100644 > --- a/.gitlab-ci.yml > +++ b/.gitlab-ci.yml > @@ -8,7 +8,7 @@ stages: > - ./automation/scripts/build 2>&1 | tee build.log >artifacts: > paths: > - - xen/.config > + - xen-config I assume the goal here is to aid in troubleshooting when we notice a failure which makes sense. You could toss that into the commit message while committing it. Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/4] automation: introduce CONTAINER_NO_PULL for containerize
On Mon, Nov 19, 2018 at 09:30:59PM +, Wei Liu wrote: > Signed-off-by: Wei Liu > --- > automation/build/README.md | 3 +++ > automation/scripts/containerize | 8 +--- > 2 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/automation/build/README.md b/automation/build/README.md > index f6cfd46f1e..d8c8a18e33 100644 > --- a/automation/build/README.md > +++ b/automation/build/README.md > @@ -52,6 +52,9 @@ understands. > > - CONTAINER_UID0: This specifies whether root is used inside the container. > > +- CONTAINER_NO_PULL: If set to 1, the script will not pull from docker hub. > + This is useful when testing container locally. > + Good addition. Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation: fix debian-{stretch, unstable}-32-gcc-debug
On Tue, Nov 20, 2018 at 02:10:02PM +, Wei Liu wrote: > They should have used .gcc-x86-32-build-debug in the first place. > > Signed-off-by: Wei Liu > --- > This patch is trivial so I intend to commit it as soon as possible to > fix Gitlab CI. Agreed. Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/3] Assorted Gitlab CI improvements
On Fri, Nov 16, 2018 at 01:12:27PM +, Wei Liu wrote: > Wei Liu (3): > automation: refactor gitlab-ci.yaml > automation: introduce some RANDCONFIG tests > automation: properly tag x86 jobs in Gitlab CI > > .gitlab-ci.yml | 309 > ++--- > 1 file changed, 162 insertions(+), 147 deletions(-) > > -- > 2.11.0 > Whole series looks great. I merged the changes to the Terraform configs as well. Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] automation: build in an openSUSE Leap container.
> On Nov 16, 2018, at 3:41 PM, Dario Faggioli wrote: > >> On Fri, 2018-11-16 at 19:50 +0100, Dario Faggioli wrote: >>> On Fri, 2018-11-16 at 18:44 +, Wei Liu wrote: On Fri, Nov 16, 2018 at 07:30:55PM +0100, Dario Faggioli wrote: >>> I have been playing with the CI system today so it could have been >>> a >>> bit >>> overwhelmed. Let's wait until next week to see if it comes back. >>> >> Ok, sure. What I'm most interested, is to see if the opensuse jobs >> pass >> (i.e., if I got the rune, the name of the container, etc, right :-) >> ). >> > And... it worked! :-) > > Now, the next step would be to add openSUSE Tumbleweed too. > > But I have a question, Tumbleweed is rolling (and it's actually rolling > quite fast); how can we handle that? > > I'd say the container image should be rebuild (or, at least, the > 'package refresh && package update' bits of the dockerfile be re- > executed), if not at every run of the pipeline, frequently enough. Can > we do that? > > I see that we have Debian unstable, which is also rolling, but do we > actually update it, or is it, basically, just a snapshot? It’s basically a snapshot. We could create a pipeline to rebuild containers periodically. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/3] automation: build Xen on Arm64
> On Nov 7, 2018, at 6:31 AM, Wei Liu wrote: > > Hi all > > This is my first attempt to quickly get something useful for Arm in Gitlab CI > with a machine borrowed from Packet.NET Thanks for getting this done Wei! For the whole series: Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] automation: build with Ubuntu 18.04
> On Nov 8, 2018, at 12:09 PM, Wei Liu wrote: > >> On Mon, Oct 22, 2018 at 04:18:51PM +0100, Wei Liu wrote: >> Signed-off-by: Wei Liu > > I will commit these two patches without acks. They are a net benefit to > Xen -- I don't think that will be controversial. > > Wei. Sounds good to me. Sorry I missed them while I was gone. If you haven’t committed them yet you have my Ack. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation: build some customised configs
On Fri, Nov 02, 2018 at 07:33:28PM +, Wei Liu wrote:
> Introduce a new directory to put in configs we care about. Modify
> build script to build with those configs.
>
> While we only introduce x86 configs initially, provision for non-x86
> configs.
>
> Signed-off-by: Wei Liu
> ---
> Cc: Jan Beulich
>
> Jan, feel free to put configs here.
> ---
> automation/configs/x86/hvm_only_config | 2 ++
> automation/configs/x86/no_hvm_pv_config | 2 ++
> automation/configs/x86/pv_only_config | 2 ++
> automation/scripts/build| 15 +++
> 4 files changed, 21 insertions(+)
> create mode 100644 automation/configs/x86/hvm_only_config
> create mode 100644 automation/configs/x86/no_hvm_pv_config
> create mode 100644 automation/configs/x86/pv_only_config
>
> diff --git a/automation/configs/x86/hvm_only_config
> b/automation/configs/x86/hvm_only_config
> new file mode 100644
> index 00..e82cc04d69
> --- /dev/null
> +++ b/automation/configs/x86/hvm_only_config
> @@ -0,0 +1,2 @@
> +CONFIG_HVM=y
> +# CONFIG_PV is not set
> diff --git a/automation/configs/x86/no_hvm_pv_config
> b/automation/configs/x86/no_hvm_pv_config
> new file mode 100644
> index 00..ed853cd358
> --- /dev/null
> +++ b/automation/configs/x86/no_hvm_pv_config
> @@ -0,0 +1,2 @@
> +# CONFIG_HVM is not set
> +# CONFIG_PV is not set
> diff --git a/automation/configs/x86/pv_only_config
> b/automation/configs/x86/pv_only_config
> new file mode 100644
> index 00..aca77b64d4
> --- /dev/null
> +++ b/automation/configs/x86/pv_only_config
> @@ -0,0 +1,2 @@
> +CONFIG_PV=y
> +# CONFIG_HVM is not set
> diff --git a/automation/scripts/build b/automation/scripts/build
> index c463b060d4..0cde1c7794 100755
> --- a/automation/scripts/build
> +++ b/automation/scripts/build
> @@ -31,3 +31,18 @@ fi
> ./configure "${cfgargs[@]}"
>
> make -j$(nproc) dist
> +
> +# Build all the configs we care about
> +case ${XEN_TARGET_ARCH} in
> +x86_64) arch=x86 ;;
> +*) exit 0 ;;
> +esac
> +
> +cfg_dir="automation/configs/${arch}"
> +for cfg in `ls ${cfg_dir}`; do
> +echo "Building $cfg"
> +rm -f xen/.config
> +make -C xen KBUILD_DEFCONFIG=../../../../${cfg_dir}/${cfg}
> XEN_CONFIG_EXPERT=y defconfig
> +make -j$(nproc) -C xen XEN_CONFIG_EXPERT=y
> +done
> +
> --
> 2.11.0
>
Seems very reasonable to me.
Acked-by: Doug Goldstein
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 10/18] INSTALL: Mention kconfig
On Mon, Oct 08, 2018 at 03:24:41PM +0100, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH 10/18] INSTALL: Mention kconfig"):
> > On 08.10.18 at 16:08, wrote:
> > > Thanks, I'll take that as an ack. (Assuming you did indeed mean
> > > `accepting' rather than `excepting'.)
> >
> > Well, no, it was not meant as an ack, merely as the absence of further
> > objections. (And yes, I did mean "accepting".)
>
> Err, OK.
>
> Doug, do you want me to propose a different or expanded wording ?
>
> Ian.
No. I think this good. It sheds light on something that was black magic
and that's good. I think you've started the conversation on how we see
XEN_CONFIG_EXPERT evolving (due to the shim config) and that's great
too. +1 from me.
--
Doug
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 17/17] automation: build Xen with CONFIG_PV and CONFIG_HVM explicitly set
On Thu, Oct 04, 2018 at 04:43:36PM +0100, Wei Liu wrote: > Signed-off-by: Wei Liu Looks good. Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 10/18] INSTALL: Mention kconfig
On Fri, Oct 05, 2018 at 06:29:09PM +0100, Ian Jackson wrote: > Firstly, add a reference to the documentation for the kconfig system. > > Secondly, warn the user about the XEN_CONFIG_EXPERT problem. > > CC: Doug Goldstein > CC: Wei Liu > CC: Jan Beulich > CC: Andrew Cooper > Signed-off-by: Ian Jackson Reviewed-by: Doug Goldstein > --- > INSTALL | 20 > 1 file changed, 20 insertions(+) > > diff --git a/INSTALL b/INSTALL > index 9aa9ebdddc..62b0162864 100644 > --- a/INSTALL > +++ b/INSTALL > @@ -19,6 +19,26 @@ following compile process. Once configure is done, make(1) > has to be > called. Also make(1) recognizes certain arguments. The following sections > will give an overview. > > +Xen Hypervisor > +== > + > +Xen itself is configured via a `kconfig' system borrowed from Linux. > +See docs/misc/kconfig.txt. > + > +Note that unlike with Linux, and contrary to that document, you cannot > +look at Kconfig files, or the default or generated config files etc., > +to find available configuration options. This is because it is only > +supported (and security supported) by the Xen Project, to change a > +small subset of the options. Attempts to change other options will be > +silently overriden. The only way to find which configuration options > +are available is to run `make menuconfig' or the like. > + > +You can counter-override this behaviour by setting XEN_CONFIG_EXPERT=y > +in your environment. However, doing this is not supported and the > +resulting configurations do not receive security support. If you set > +this varible there is nothing stopping you setting dangerously > +experimental combinations of features - not even any warnings. Not really true because the shim is supported and relies on XEN_CONFIG_EXPERT but certainly better to make users aware than blindly hiding everything from them. I'd still argue that eventually we'll get rid of this because most distros build with XEN_CONFIG_EXPERT on and most Xen devs I know just have it set in their environment. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] automation: introduce a new variable to control container user
On Tue, Sep 25, 2018 at 03:19:31PM +0100, Wei Liu wrote: > Sometimes it is handy to create a container and play with its setup > manually as root. > > Signed-off-by: Wei Liu Acked-by: Doug Goldstein Thanks for the improvement! ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation: introduce a new variable to control container user
On Mon, Sep 24, 2018 at 05:18:29PM +0100, Wei Liu wrote:
> Sometimes it is handy to create a container and play as root with its
> setup manually.
>
> Signed-off-by: Wei Liu
> ---
> automation/scripts/containerize | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/automation/scripts/containerize b/automation/scripts/containerize
> index bf9af589a8..ea3c7378aa 100755
> --- a/automation/scripts/containerize
> +++ b/automation/scripts/containerize
> @@ -23,6 +23,12 @@ case "_${CONTAINER}" in
> _stretch|_) CONTAINER="${BASE}/debian:stretch" ;;
> esac
>
> +# Use this variable to control whehter root should be used
> +case "_${CONTAINER_ROOT}" in
> +_1) userarg= ;;
> +_0|_) userarg="-u $(id -u)" ;;
> +esac
How would you feel about CONTAINER_UID0 instead? I just fear that "ROOT"
has quite a few meanings. e.g top of the filesystem? The working dir
inside of the container?
Mind documenting this in automation/build/README.md ? I should likely
move part of this file that describes the variables up a directory.
--
Doug
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation: skip some branches in gitlab CI
On Mon, Sep 17, 2018 at 09:33:41AM +0100, Wei Liu wrote: > Ignore branches which are always fast-forwarded to staging* branches. > List of filters taken from Travis CI setup. > > Signed-off-by: Wei Liu Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation: specify -j$(nproc) in build script
On Thu, Sep 06, 2018 at 03:55:59PM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu
> ---
> automation/scripts/build | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/automation/scripts/build b/automation/scripts/build
> index 054226bd73..c463b060d4 100755
> --- a/automation/scripts/build
> +++ b/automation/scripts/build
> @@ -30,4 +30,4 @@ fi
>
> ./configure "${cfgargs[@]}"
>
> -make dist
> +make -j$(nproc) dist
> --
> 2.11.0
>
Acked-by: Doug Goldstein
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] build: remove tboot make targets
On Mon, Aug 20, 2018 at 02:33:10AM -0600, Jan Beulich wrote: > >>> On 19.08.18 at 04:22, wrote: > > The tboot targets are woefully out of date. These should really be > > retired because setting up tboot is more complex than the build process > > for it. > > > > Signed-off-by: Doug Goldstein > > Acked-by: Jan Beulich > > But I think you would better have Cc-ed the TXT/TBOOT maintainers > (now done), as it was presumably them having introduced these > targets. Even if the chance if high to not see any response, we > should at least give them a chance to chime in. Just a one week ping. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] automation: enable building rombios with clang
On Fri, Aug 24, 2018 at 04:34:35PM +0100, Wei Liu wrote:
> On Fri, Aug 24, 2018 at 10:32:24AM -0500, Doug Goldstein wrote:
> > On Fri, Aug 24, 2018 at 04:22:47PM +0100, Wei Liu wrote:
> > > Previously it is disabled because the embedded ipxe can't be built
> > > with clang. Now that ipxe is split out we can use --with-system-ipxe
> > > to work around the issue.
> > >
> > > Signed-off-by: Wei Liu
> > > ---
> > > +# iPXE cannot be built with clang
> > > +cfgargs+=("--with-system-ipxe=/usr/lib/ipxe/ipxe.pxe")
> >
> > Did we ever get all the containers updated with this file in place?
>
> No. I didn't. Do we care? Xen's build system doesn't check if that file
> exists. It merely puts the string into appropriate places.
>
> Wei.
Well then that works for me. Just wondering if you've pushed a branch
with this and had GitLab run over it?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] automation: enable building rombios with clang
On Fri, Aug 24, 2018 at 04:22:47PM +0100, Wei Liu wrote:
> Previously it is disabled because the embedded ipxe can't be built
> with clang. Now that ipxe is split out we can use --with-system-ipxe
> to work around the issue.
>
> Signed-off-by: Wei Liu
> ---
> +# iPXE cannot be built with clang
> +cfgargs+=("--with-system-ipxe=/usr/lib/ipxe/ipxe.pxe")
Did we ever get all the containers updated with this file in place?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] rombios: work around clang's -Waddress-of-packed-member
On Fri, Aug 24, 2018 at 04:22:15PM +0100, Wei Liu wrote: > Building rombios with clang XXX fails with: > > tcgbios.c:1519:34: error: taking address of packed member 'u' of class or > structure 'pushad_regs_t' may result in an unaligned pointer value > [-Werror,-Waddress-of-packed-member] > ®s->u.r32.edx); >^~~ > > Work around that by using an intermediate variable. > > Signed-off-by: Wei Liu Reviewed-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] tools: fix uninstall: tests/x86_emulator, Linux hotplug
On Mon, Aug 20, 2018 at 11:42:30AM -0700, Christopher Clark wrote: > Fixing top-level "make uninstall": > > tools/tests/x86_emulator is missing an uninstall target, which causes > failure. Trivial to add one since it installs nothing, so do that. > > Linux hotplug uninstall returns success but doesn't actually remove what > it installed. The Makefile variables are obfuscating incorrect logic, so > strip them out and match existing code for xen-watchdog which does work. > > Signed-off-by: Christopher Clark Reviewed-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] build: remove tboot make targets
The tboot targets are woefully out of date. These should really be retired because setting up tboot is more complex than the build process for it. Signed-off-by: Doug Goldstein --- Everyone knows my feeling about the Xen build system being a meta-distro builder. This just removes something that never really belonged integrated in the Xen build system. The best option would be documentation instead of a make target to explain how to setup tboot along with the necessary ACMs and the policy generation. But then again tboot has its own docs covering that. The Linux kernel doesn't have a make target for tboot so why should Xen? This is my rant while I tried to keep the rant-y bits out of the commit message. --- Makefile | 44 README | 5 - 2 files changed, 49 deletions(-) diff --git a/Makefile b/Makefile index 1d43044033..d959cd5b47 100644 --- a/Makefile +++ b/Makefile @@ -291,11 +291,6 @@ help: @echo ' uninstall - attempt to remove installed Xen tools' @echo ' (use with extreme care!)' @echo - @echo 'Trusted Boot (tboot) targets:' - @echo ' build-tboot - download and build the tboot module' - @echo ' install-tboot - download, build, and install the tboot module' - @echo ' clean-tboot - clean the tboot module if it exists' - @echo @echo 'Package targets:' @echo ' src-tarball-release - make a source tarball with xen and qemu tagged with a release' @echo ' src-tarball - make a source tarball with xen and qemu tagged with git describe' @@ -324,46 +319,7 @@ uninstall-docs: .PHONY: uninstall uninstall: D=$(DESTDIR) uninstall: uninstall-tools-public-headers $(TARGS_UNINSTALL) - rm -rf $(D)/boot/tboot* .PHONY: xenversion xenversion: @$(MAKE) --no-print-directory -C xen xenversion - -# -# tboot targets -# - -TBOOT_TARFILE = tboot-20090330.tar.gz -#TBOOT_BASE_URL = http://downloads.sourceforge.net/tboot -TBOOT_BASE_URL = $(XEN_EXTFILES_URL) - -.PHONY: build-tboot -build-tboot: download_tboot - $(MAKE) -C tboot build - -.PHONY: install-tboot -install-tboot: download_tboot - $(MAKE) -C tboot install - -.PHONY: dist-tboot -dist-tboot: download_tboot - $(MAKE) DESTDIR=$(DISTDIR)/install -C tboot dist - -.PHONY: clean-tboot -clean-tboot: - [ ! -d tboot ] || $(MAKE) -C tboot clean - -.PHONY: distclean-tboot -distclean-tboot: - [ ! -d tboot ] || $(MAKE) -C tboot distclean - -.PHONY: download_tboot -download_tboot: tboot/Makefile - -tboot/Makefile: tboot/$(TBOOT_TARFILE) - [ -e tboot/Makefile ] || tar -xzf tboot/$(TBOOT_TARFILE) -C tboot/ --strip-components 1 - -tboot/$(TBOOT_TARFILE): - mkdir -p tboot - wget -O tboot/$(TBOOT_TARFILE) $(TBOOT_BASE_URL)/$(TBOOT_TARFILE) diff --git a/README b/README index 4b95b21c7b..3a497fb064 100644 --- a/README +++ b/README @@ -199,8 +199,3 @@ http://sourceforge.net/projects/tboot. This project hosts the code in a mercurial repo at http://tboot.sourceforge.net/hg/tboot.hg and contains tarballs of the source. Instructions in the tboot README describe how to modify grub.conf to use tboot to launch Xen. - -There are optional targets as part of Xen's top-level makefile that will -download and build tboot: install-tboot, build-tboot, dist-tboot, clean-tboot. -These will download the latest tar file from the SourceForge site using wget, -then build/install/dist according to Xen's settings. -- 2.16.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 3/4] automation: remove dead code from containerize
This is more dead code.
Signed-off-by: Doug Goldstein
Reviewed-by: Wei Liu
---
automation/scripts/containerize | 5 -
1 file changed, 5 deletions(-)
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index 7f0eb0a..7bdfc21 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -23,10 +23,6 @@ case "_${CONTAINER}" in
_stretch|_) CONTAINER="${BASE}/debian:stretch" ;;
esac
-# get our container name and version
-containid=${CONTAINER%:*}
-containver=${CONTAINER#*:}
-
# Save the commands for future use
cmd=$@
@@ -74,7 +70,6 @@ fi
# Kick off Docker
einfo "*** Launching container ..."
exec docker run \
-${DOCKER_ARGS} \
${SSH_AUTH_SOCK:+-e SSH_AUTH_SOCK="/tmp/ssh-agent/${SSH_AUTH_NAME}"} \
-v "${CONTAINER_PATH}":/build:rw \
-v "${HOME}/.ssh":/root/.ssh:ro \
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 0/4] This series improves the containerize script to hopefully make it more
friendly for folks to use to locally do build tests under different distros. change from v1: - first patch switch to -z as it makes more sense Doug Goldstein (4): automation: standardize containerize env names automation: drop container name from containerize automation: remove dead code from containerize automation: ensure created are not owned as root automation/build/README.md | 15 +-- automation/scripts/containerize | 21 + 2 files changed, 10 insertions(+), 26 deletions(-) base-commit: 008a8fb249b9d433a64bc59a93075bcb4b01e3d3 -- git-series 0.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 2/4] automation: drop container name from containerize
This was something that existed for some scripting support for a totally
unrelated project and when I copied this script I failed to remove it so
this removes it. Build containers for Xen are best as ephemeral
environments and should just utilizes Docker's default container naming
behavior.
Signed-off-by: Doug Goldstein
Reviewed-by: Wei Liu
---
automation/build/README.md | 5 -
automation/scripts/containerize | 7 +--
2 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/automation/build/README.md b/automation/build/README.md
index 987533a..bf11317 100644
--- a/automation/build/README.md
+++ b/automation/build/README.md
@@ -53,11 +53,6 @@ understands.
- XEN_CONFIG_EXPERT: If this is defined in your shell it will be
automatically passed through to the container.
-- CONTAINER_NAME: By default the container name is set based on the
- container itself so that its easy to attach other terminals to your
- container. This however prevents you from running multiple containers
- of the same version. Override the name value to cause it to name
- the container differently on start.
Building a container
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index f4ff24c..7f0eb0a 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -65,11 +65,6 @@ if [[ -n ${SSH_AUTH_SOCK} ]]; then
fi
fi
-# if we got the CONTAINER_NAME env variable then use that for our name
-if [[ -n ${CONTAINER_NAME} ]]; then
-name="--name ${CONTAINER_NAME}"
-fi
-
# Figure out the base of what we want as our sources
# by using the top of the git repo
if [[ -z ${CONTAINER_PATH} ]]; then
@@ -85,7 +80,7 @@ exec docker run \
-v "${HOME}/.ssh":/root/.ssh:ro \
${SSH_AUTH_DIR:+-v "${SSH_AUTH_DIR}":/tmp/ssh-agent} \
${XEN_CONFIG_EXPERT:+-e XEN_CONFIG_EXPERT=${XEN_CONFIG_EXPERT}} \
-${CONTAINER_ARGS} ${name} \
+${CONTAINER_ARGS} \
-${termint}i --rm -- \
${CONTAINER} \
${cmd}
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 1/4] automation: standardize containerize env names
Standardized all the environment variable names that the containerize
script uses to start with CONTAINER_
Signed-off-by: Doug Goldstein
---
automation/build/README.md | 10 +-
automation/scripts/containerize | 10 --
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/automation/build/README.md b/automation/build/README.md
index be4526c..987533a 100644
--- a/automation/build/README.md
+++ b/automation/build/README.md
@@ -40,13 +40,16 @@ understands.
CONTAINER=centos72 ./automation/scripts/containerize make
```
-- WORKDIR: This overrides the path that will be available under the
+- CONTAINER_PATH: This overrides the path that will be available under the
`/build` directory in the container, which is the default path.
```
- WORKDIR=/some/other/path ./automation/scripts/containerize ls
+ CONTAINER_PATH=/some/other/path ./automation/scripts/containerize ls
```
+- CONTAINER_ARGS: Allows you to pass extra arguments to Docker
+ when starting the container.
+
- XEN_CONFIG_EXPERT: If this is defined in your shell it will be
automatically passed through to the container.
@@ -56,9 +59,6 @@ understands.
of the same version. Override the name value to cause it to name
the container differently on start.
-- EXTRA_CONTAINER_ARGS: Allows you to pass extra arguments to Docker
- when starting the container.
-
Building a container
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index f7f6642..f4ff24c 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -72,10 +72,8 @@ fi
# Figure out the base of what we want as our sources
# by using the top of the git repo
-if [[ -n ${WORKDIR} ]]; then
-WORKDIR="${WORKDIR}"
-else
-WORKDIR=$(git rev-parse --show-toplevel)
+if [[ -z ${CONTAINER_PATH} ]]; then
+CONTAINER_PATH=$(git rev-parse --show-toplevel)
fi
# Kick off Docker
@@ -83,11 +81,11 @@ einfo "*** Launching container ..."
exec docker run \
${DOCKER_ARGS} \
${SSH_AUTH_SOCK:+-e SSH_AUTH_SOCK="/tmp/ssh-agent/${SSH_AUTH_NAME}"} \
--v "${WORKDIR}":/build:rw \
+-v "${CONTAINER_PATH}":/build:rw \
-v "${HOME}/.ssh":/root/.ssh:ro \
${SSH_AUTH_DIR:+-v "${SSH_AUTH_DIR}":/tmp/ssh-agent} \
${XEN_CONFIG_EXPERT:+-e XEN_CONFIG_EXPERT=${XEN_CONFIG_EXPERT}} \
-${EXTRA_CONTAINER_ARGS} ${name} \
+${CONTAINER_ARGS} ${name} \
-${termint}i --rm -- \
${CONTAINER} \
${cmd}
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 4/4] automation: ensure created are not owned as root
By default the container runs as the root user and since the source tree
is bind mounted into the container, any file is created and owned by the
root user which harms ergonomics when working outside of the container
environment. This maps the root user within the container to the uid of
the user outside of the container so files are not owned by root.
Signed-off-by: Doug Goldstein
Reviewed-by: Wei Liu
---
automation/scripts/containerize | 1 +
1 file changed, 1 insertion(+)
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index 7bdfc21..bf9af58 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -70,6 +70,7 @@ fi
# Kick off Docker
einfo "*** Launching container ..."
exec docker run \
+-u $(id -u) \
${SSH_AUTH_SOCK:+-e SSH_AUTH_SOCK="/tmp/ssh-agent/${SSH_AUTH_NAME}"} \
-v "${CONTAINER_PATH}":/build:rw \
-v "${HOME}/.ssh":/root/.ssh:ro \
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/4] This series improves the containerize script to hopefully make it more
friendly for folks to use to locally do build tests under different distros. Doug Goldstein (4): automation: standardize containerize env names automation: drop container name from containerize automation: remove dead code from containerize automation: ensure created are not owned as root automation/build/README.md | 15 +-- automation/scripts/containerize | 21 ++--- 2 files changed, 11 insertions(+), 25 deletions(-) base-commit: acd00a303378ce48bd6bbd8a579f1fe2f1b21a7d -- git-series 0.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/2] automation: CentOS 7.x container
Add a CentOS 7.x container that tracks the latest CentOS 7 release along with the GitLab CI changes to build with it. A test run is available here: https://gitlab.com/cardoe/xen/pipelines/26695770 Doug Goldstein (2): automation: add CentOS 7.x image ci: enable builds with CentOS 7.x .gitlab-ci.yml | 16 +- automation/build/centos/7.dockerfile | 49 +- automation/scripts/containerize | 1 +- 3 files changed, 66 insertions(+) create mode 100644 automation/build/centos/7.dockerfile base-commit: acd00a303378ce48bd6bbd8a579f1fe2f1b21a7d -- git-series 0.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/2] automation: add CentOS 7.x image
This image will always track the latest CentOS 7.x release. Add this
container to containerize for easy access.
Signed-off-by: Doug Goldstein
---
automation/build/centos/7.dockerfile | 49 +-
automation/scripts/containerize | 1 +-
2 files changed, 50 insertions(+)
create mode 100644 automation/build/centos/7.dockerfile
diff --git a/automation/build/centos/7.dockerfile
b/automation/build/centos/7.dockerfile
new file mode 100644
index 000..e37d9d7
--- /dev/null
+++ b/automation/build/centos/7.dockerfile
@@ -0,0 +1,49 @@
+FROM centos:7
+LABEL maintainer.name="The Xen Project" \
+ maintainer.email="xen-devel@lists.xenproject.org"
+
+RUN mkdir /build
+WORKDIR /build
+
+# work around https://github.com/moby/moby/issues/10180
+# and add EPEL for dev86
+RUN rpm --rebuilddb && \
+yum -y install \
+yum-plugin-ovl \
+epel-release \
+&& yum clean all && \
+rm -rf /var/cache/yum
+
+# install Xen depends
+RUN yum -y install \
+gcc \
+gcc-c++ \
+ncurses-devel \
+zlib-devel \
+openssl-devel \
+python-devel \
+libuuid-devel \
+pkgconfig \
+gettext \
+flex \
+bison \
+libaio-devel \
+glib2-devel \
+yajl-devel \
+pixman-devel \
+glibc-devel \
+glibc-devel.i686 \
+make \
+binutils \
+git \
+wget \
+acpica-tools \
+python-markdown \
+patch \
+checkpolicy \
+dev86 \
+xz-devel \
+bzip2 \
+nasm \
+&& yum clean all && \
+rm -rf /var/cache/yum
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index 7253617..f7f6642 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -15,6 +15,7 @@ die() {
#
BASE="registry.gitlab.com/xen-project/xen"
case "_${CONTAINER}" in
+_centos7) CONTAINER="${BASE}/centos:7" ;;
_centos72) CONTAINER="${BASE}/centos:7.2" ;;
_trusty) CONTAINER="${BASE}/ubuntu:trusty" ;;
_xenial) CONTAINER="${BASE}/ubuntu:xenial" ;;
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/2] ci: enable builds with CentOS 7.x
Add the CentOS 7.x images to be used for build testing. Signed-off-by: Doug Goldstein --- .gitlab-ci.yml | 16 1 file changed, 16 insertions(+) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 1b9877b..6328da9 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -39,6 +39,22 @@ centos-7-2-gcc-debug: debug: y XEN_TARGET_ARCH: x86_64 +centos-7-gcc: + <<: *build + variables: +<<: *gcc +CONTAINER: centos:7 +debug: n +XEN_TARGET_ARCH: x86_64 + +centos-7-gcc-debug: + <<: *build + variables: +<<: *gcc +CONTAINER: centos:7 +debug: y +XEN_TARGET_ARCH: x86_64 + debian-jessie-clang: <<: *build variables: -- git-series 0.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/4] automation: standardize containerize env names
Standardized all the environment variable names that the containerize
script uses to start with CONTAINER_
Signed-off-by: Doug Goldstein
---
automation/build/README.md | 10 +-
automation/scripts/containerize | 10 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/automation/build/README.md b/automation/build/README.md
index be4526c..987533a 100644
--- a/automation/build/README.md
+++ b/automation/build/README.md
@@ -40,13 +40,16 @@ understands.
CONTAINER=centos72 ./automation/scripts/containerize make
```
-- WORKDIR: This overrides the path that will be available under the
+- CONTAINER_PATH: This overrides the path that will be available under the
`/build` directory in the container, which is the default path.
```
- WORKDIR=/some/other/path ./automation/scripts/containerize ls
+ CONTAINER_PATH=/some/other/path ./automation/scripts/containerize ls
```
+- CONTAINER_ARGS: Allows you to pass extra arguments to Docker
+ when starting the container.
+
- XEN_CONFIG_EXPERT: If this is defined in your shell it will be
automatically passed through to the container.
@@ -56,9 +59,6 @@ understands.
of the same version. Override the name value to cause it to name
the container differently on start.
-- EXTRA_CONTAINER_ARGS: Allows you to pass extra arguments to Docker
- when starting the container.
-
Building a container
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index 7253617..010ed39 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -71,10 +71,10 @@ fi
# Figure out the base of what we want as our sources
# by using the top of the git repo
-if [[ -n ${WORKDIR} ]]; then
-WORKDIR="${WORKDIR}"
+if [[ -n ${CONTAINER_PATH} ]]; then
+:
else
-WORKDIR=$(git rev-parse --show-toplevel)
+CONTAINER_PATH=$(git rev-parse --show-toplevel)
fi
# Kick off Docker
@@ -82,11 +82,11 @@ einfo "*** Launching container ..."
exec docker run \
${DOCKER_ARGS} \
${SSH_AUTH_SOCK:+-e SSH_AUTH_SOCK="/tmp/ssh-agent/${SSH_AUTH_NAME}"} \
--v "${WORKDIR}":/build:rw \
+-v "${CONTAINER_PATH}":/build:rw \
-v "${HOME}/.ssh":/root/.ssh:ro \
${SSH_AUTH_DIR:+-v "${SSH_AUTH_DIR}":/tmp/ssh-agent} \
${XEN_CONFIG_EXPERT:+-e XEN_CONFIG_EXPERT=${XEN_CONFIG_EXPERT}} \
-${EXTRA_CONTAINER_ARGS} ${name} \
+${CONTAINER_ARGS} ${name} \
-${termint}i --rm -- \
${CONTAINER} \
${cmd}
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4/4] automation: ensure created are not owned as root
By default the container runs as the root user and since the source tree
is bind mounted into the container, any file is created and owned by the
root user which harms ergonomics when working outside of the container
environment. This maps the root user within the container to the uid of
the user outside of the container so files are not owned by root.
Signed-off-by: Doug Goldstein
---
automation/scripts/containerize | 1 +
1 file changed, 1 insertion(+)
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index d17f5ff..7d297d7 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -71,6 +71,7 @@ fi
# Kick off Docker
einfo "*** Launching container ..."
exec docker run \
+-u $(id -u) \
${SSH_AUTH_SOCK:+-e SSH_AUTH_SOCK="/tmp/ssh-agent/${SSH_AUTH_NAME}"} \
-v "${CONTAINER_PATH}":/build:rw \
-v "${HOME}/.ssh":/root/.ssh:ro \
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/4] automation: remove dead code from containerize
This is more dead code.
Signed-off-by: Doug Goldstein
---
automation/scripts/containerize | 5 -
1 file changed, 5 deletions(-)
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index 2cb8021..d17f5ff 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -22,10 +22,6 @@ case "_${CONTAINER}" in
_stretch|_) CONTAINER="${BASE}/debian:stretch" ;;
esac
-# get our container name and version
-containid=${CONTAINER%:*}
-containver=${CONTAINER#*:}
-
# Save the commands for future use
cmd=$@
@@ -75,7 +71,6 @@ fi
# Kick off Docker
einfo "*** Launching container ..."
exec docker run \
-${DOCKER_ARGS} \
${SSH_AUTH_SOCK:+-e SSH_AUTH_SOCK="/tmp/ssh-agent/${SSH_AUTH_NAME}"} \
-v "${CONTAINER_PATH}":/build:rw \
-v "${HOME}/.ssh":/root/.ssh:ro \
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/4] automation: drop container name from containerize
This was something that existed for some scripting support for a totally
unrelated project and when I copied this script I failed to remove it so
this removes it. Build containers for Xen are best as ephemeral
environments and should just utilizes Docker's default container naming
behavior.
Signed-off-by: Doug Goldstein
---
automation/build/README.md | 5 -
automation/scripts/containerize | 7 +--
2 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/automation/build/README.md b/automation/build/README.md
index 987533a..bf11317 100644
--- a/automation/build/README.md
+++ b/automation/build/README.md
@@ -53,11 +53,6 @@ understands.
- XEN_CONFIG_EXPERT: If this is defined in your shell it will be
automatically passed through to the container.
-- CONTAINER_NAME: By default the container name is set based on the
- container itself so that its easy to attach other terminals to your
- container. This however prevents you from running multiple containers
- of the same version. Override the name value to cause it to name
- the container differently on start.
Building a container
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index 010ed39..2cb8021 100755
--- a/automation/scripts/containerize
+++ b/automation/scripts/containerize
@@ -64,11 +64,6 @@ if [[ -n ${SSH_AUTH_SOCK} ]]; then
fi
fi
-# if we got the CONTAINER_NAME env variable then use that for our name
-if [[ -n ${CONTAINER_NAME} ]]; then
-name="--name ${CONTAINER_NAME}"
-fi
-
# Figure out the base of what we want as our sources
# by using the top of the git repo
if [[ -n ${CONTAINER_PATH} ]]; then
@@ -86,7 +81,7 @@ exec docker run \
-v "${HOME}/.ssh":/root/.ssh:ro \
${SSH_AUTH_DIR:+-v "${SSH_AUTH_DIR}":/tmp/ssh-agent} \
${XEN_CONFIG_EXPERT:+-e XEN_CONFIG_EXPERT=${XEN_CONFIG_EXPERT}} \
-${CONTAINER_ARGS} ${name} \
+${CONTAINER_ARGS} \
-${termint}i --rm -- \
${CONTAINER} \
${cmd}
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] automation: build with debian unstable
On Mon, Jul 23, 2018 at 05:57:35PM +0100, Wei Liu wrote: > Signed-off-by: Wei Liu While this is good and provisionally I would say: Acked-by: Doug Goldstein I'd like us to hold off on committing this until other changes land to fix the build issues that are currently happening on Debian unstable. e.g. iPXE doesn't work as well as OVMF. I've seen a patch on the list for the latter. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] automation: add debian unstable images
On Mon, Jul 23, 2018 at 05:57:34PM +0100, Wei Liu wrote: > This will get us the latest toolchain available in Debian. > > Signed-off-by: Wei Liu Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation: build with 32 bit stretch
On Mon, Jul 23, 2018 at 09:04:46AM +0100, Wei Liu wrote: > Signed-off-by: Wei Liu Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6] automation: introduce a script for build test
On Wed, Jul 25, 2018 at 10:24:24AM +0100, Wei Liu wrote: > Signed-off-by: Ian Jackson > Signed-off-by: Wei Liu > --- > This is a script I wrote previously for build test. > > Given it basically runs a set of commands on every commit, maybe it should > be named for-each-commit.sh ? So if we do that can we make it clear that there's a default action that's going to be run? Mentally I'd expect a script called like that would require a command that it would execute but you do have a default. > + > +while read num rev; do > +echo "Testing $num $rev" > + > +git checkout $rev > +ret=$? > +if test $ret -ne 0; then > +echo "Failed to checkout $num $rev with $ret" > +break > +fi > + > +if test $# -eq 0 ; then > +git clean -fdx && ./configure && make -j4 maybe some comment in the code like "hey someone reading me this is the default command" Overall I think this is a good addition to the tree. If people feel different than I do about the default command then feel free to commit with my: Reviewed-by: Doug Goldstein -- Doug ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: correct DEFCONFIG_LIST Kconfig item
On Tue, Jul 24, 2018 at 07:40:11AM -0600, Jan Beulich wrote: > >>> On 10.07.18 at 12:18, wrote: > >>>> On 10.07.18 at 10:31, wrote: > >> The default value of DEFCONFIG_LIST is wrong: it should be the value of > >> the configured ARCH_DEFCONFIG item, not the string "$ARCH_DEFCONFIG". > > > > Makse sense and matches Linux, but I'd still prefer to have Doug's > > consent here. > > Ping? > Apologies. I've checked and the patch is correct. Reviewed-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation: introduce a script for build test
On Tue, Jul 24, 2018 at 05:56:51PM +0100, Wei Liu wrote: > Signed-off-by: Ian Jackson > Signed-off-by: Wei Liu > --- > This is a script I wrote previously for build test. Goal here is to bisect a series to find the build failure? We could allow git bisect to do the work and just build and return success or failure instead of having to walk it by hand. I don't have one specifically for Xen but on other projects I've got something like: ./scripts/bisect.sh which looks roughly like: #!/bin/sh git bisect start $2 $1 git bisect run ./scripts/basic-build.sh Then my ./scripts/basic-build.sh would look like: #!/bin/sh git clean -xdf ./configure || exit 1 make > > Cc: Andrew Cooper > Cc: George Dunlap > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Konrad Rzeszutek Wilk > Cc: Stefano Stabellini > Cc: Tim Deegan > Cc: Wei Liu > Cc: Julien Grall > Cc: Anthony PERARD > > v5: > 1. Use bash so that while do ... done < () works. > 2. Move script to automation directory. > > v4: > 1. Check, save/restore $?. > 2. Don't use trap, check exit code directly. > 3. More error messages. > > v3: > 1. Use git-clean in default rune. > 2. Print more friendly message. > 3. Restore HEAD automatically. > --- > automation/scripts/build-test.sh | 68 > > 1 file changed, 68 insertions(+) > create mode 100755 automation/scripts/build-test.sh > > diff --git a/automation/scripts/build-test.sh > b/automation/scripts/build-test.sh > new file mode 100755 > index 00..885e5f7a13 > --- /dev/null > +++ b/automation/scripts/build-test.sh > @@ -0,0 +1,68 @@ > +#!/bin/bash > + > +# Run command on every commit within the range specified. If no command is > +# provided, use the default one to clean and build the whole tree. > +# > +# The default rune is rather simple. To do a cross-build, please put your > usual > +# build rune in a shell script and invoke it with this script. > + > +if ! test -f xen/common/kernel.c; then > +echo "Please run this script from top-level directory" > +exit 1 > +fi You could make it run from anywhere if you did: pushd `git rev-parse --show-toplevel` ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On Tue, Jul 24, 2018 at 04:04:05AM -0600, Jan Beulich wrote: > >>> On 24.07.18 at 11:43, wrote: > > On Tue, Jul 24, 2018 at 03:34:51AM -0600, Jan Beulich wrote: > >> >>> On 24.07.18 at 11:24, wrote: > >> > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote: > >> >> >>> On 23.07.18 at 18:40, wrote: > >> >> > # How does this impact me? > >> >> > The contribution workflow is *not* impacted by this change, but once > >> >> > up and > >> > > >> >> > running the following will happen once you post a patch or patch > >> >> > series to > >> >> > xen-devel: > >> >> > * Patchwork will take patch series from the mailing list and applies > >> >> > it > >> >> > * CI/DC testing is triggered > >> >> > * A test report will be sent as a mail to the patch or the series > >> >> > (aka the 00 patch of the series) > >> >> > > >> >> > This does mean though that series which do not build or show other > >> >> > issues, > >> >> > will likely not be reviewed until the tests pass. This would lessen > >> >> > the > >> >> > burden on reviewers, as they will know whether the code submitted > >> >> > builds on a > >> >> > wide array of environments. > >> >> > >> >> So how are dependencies between series intended to be dealt with? It > >> >> is not uncommon for someone to say "applies only on top of xyz". The > >> >> implication of "will likely not be reviewed until the tests pass" seems > >> >> unsuitable to me in such a case. > >> >> > >> > > >> > We have been asking everyone to rebase to staging before posting a new > >> > version for a long time. It is natural for the bot to assume that > >> > everything should apply on top of staging. That would provide most value > >> > to the community. > >> > > >> > For special cases like you just mention, we should aim to provide > >> > mechanisms to manually appoint a branch to be tested. > >> > >> I'm afraid I disagree again: Tools used should not be dictated. I'm > >> using quilt, not git for my work, and hence I don't maintain any > >> branches anywhere. > > > > Alright. > > > > First, I don't think I said that only git would be supported. > > Git is the most prevalent VCS nowadays, and most developers use it, so > > it would make sense to support it first. If you want quilt, we can > > certainly look into that. But I'm afraid if you don't say what you > > specifically need, nothing can be done in that regard. > > Well, if you thought of other than git, then I'm afraid I lack > understanding of where such a "branch" should be coming from. > My first and foremost requirement is that, as stated pretty close > to the top, the contribution workflow be *not* impacted. Any > setting up of anything that I'd need to do would be contrary to > that. > > > Second, it is up to individual whether they want to use a certain tool > > or not. If you don't want to use this infrastructure for whatever > > reason, that's OK. You're only missing out all the work in the community > > has done, but you should be able to use your own workflow just fine. > > Then I maybe misunderstood Lars'es mail: I've gained the > impression that the picking up of patches would be automatic, > i.e. without me telling to system to do so. As it would presumably > send its (failure) mails back to the author, I'd expect to get what > effectively is spam in the described case. > > I'm afraid my personal bar for any such automation is pretty > high: There must not ever be any negative effect from such an > addition. Positive effects would of course be very welcome. I > realize this is an unrealistic goal, but it should at least come > close (perhaps after some initial learning phase). But this implies > that at least in theory it is possible to come close in the first > place, which I can't take for given with the information I've been > provided so far. > > Jan I hope you're not advocating for no progress until the perfect system is achieved without giving anyone the opportunity to develop a system since its impossible to develop a perfect system in the first go. The ultimate goal here is to take patches that are posted to the mailing list, apply them on top of staging and build them against a variety of compiler combos coming from different distros. The results would then be emailed as a reply to the cover letter. The idea is that this would help maintainers/reviewers out as they could tell the submitter that it won't get reviewed until it at least compiles. The first improvement to the entire system I'd like to make is automatic code-style checking. But that is depending on clang-format landing the Xen code-style plugin. Would you at least agree that this would be useful to some maintainers and something some subset of folks would like to see? This isn't necessarily targeted at code that you personally submit but folks that are less frequent contributors. I've seen on numerous occasions a new contributor making a patch against an outdated branch and this would help there for example.
Re: [Xen-devel] automation: Creating a patchwork instance to improve pre-commit build testing
On Tue, Jul 24, 2018 at 03:32:09PM +0100, George Dunlap wrote: > On 07/24/2018 10:34 AM, Jan Beulich wrote: > On 24.07.18 at 11:24, wrote: > >> On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote: > >> On 23.07.18 at 18:40, wrote: > # How does this impact me? > The contribution workflow is *not* impacted by this change, but once up > and > >> > running the following will happen once you post a patch or patch series > to > xen-devel: > * Patchwork will take patch series from the mailing list and applies it > * CI/DC testing is triggered > * A test report will be sent as a mail to the patch or the series (aka > the 00 patch of the series) > > This does mean though that series which do not build or show other > issues, > will likely not be reviewed until the tests pass. This would lessen the > burden on reviewers, as they will know whether the code submitted builds > on a > wide array of environments. > >>> > >>> So how are dependencies between series intended to be dealt with? It > >>> is not uncommon for someone to say "applies only on top of xyz". The > >>> implication of "will likely not be reviewed until the tests pass" seems > >>> unsuitable to me in such a case. > >>> > >> > >> We have been asking everyone to rebase to staging before posting a new > >> version for a long time. It is natural for the bot to assume that > >> everything should apply on top of staging. That would provide most value > >> to the community. > >> > >> For special cases like you just mention, we should aim to provide > >> mechanisms to manually appoint a branch to be tested. > > > > I'm afraid I disagree again: Tools used should not be dictated. I'm > > using quilt, not git for my work, and hence I don't maintain any > > branches anywhere. > > Well it's never been our habit to review patch series sent against > random private branches. (x86-next not being a random private branch.) > The idea would be that you put a tag in the message somewhere that > indicates what the patchbot should do. This would probably be just the > message-id of the patch series, given that (steady state) your previous > series would have had the bot reply to it with a link. Something like this: > > Prerequisite-series: <5b506a6e0278001d5...@prv1-mh.provo.novell.com> > > If the sender doesn't add the prerequisite series, then of course it > won't apply; but the reviewer can choose to ignore the failure in that case. > > -George So fwiw, there's a tool called git-series (the author says he's working on integrating its functionality into the git upstream) that does exactly this. Most of my recent patches have been sent with it and you'll actually see what commit from staging my patches are based on and if I wanted I could record instead the message-id of a posted series it would depend on. I've spoken with the patchwork folks about support that tag as well. -- Doug ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation: enable building rombios with clang
On Tue, Jul 17, 2018 at 09:39:35AM +0100, Wei Liu wrote:
> Previously it is disabled because the embedded ipxe can't be built
> with clang. Now that ipxe is split out we can use --with-system-ipxe
> to work around the issue.
>
> Signed-off-by: Wei Liu
> ---
> Depends on the ipxe series just committed.
> ---
> automation/scripts/build | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/automation/scripts/build b/automation/scripts/build
> index 054226bd73..4dcaabf4bd 100755
> --- a/automation/scripts/build
> +++ b/automation/scripts/build
> @@ -16,8 +16,8 @@ cfgargs+=("--enable-docs")
> if [[ "${CC}" == "clang" ]]; then
> # SeaBIOS cannot be built with clang
> cfgargs+=("--with-system-seabios=/usr/share/seabios/bios.bin")
> -# iPXE cannot be built with clang so we cannot build rombios
> -cfgargs+=("--disable-rombios")
> +# iPXE cannot be built with clang
> +cfgargs+=("--with-system-ipxe=/usr/share/ipxe/ipxe.bin")
This file doesn't exist on the Ubuntu containers I've tried. Even after
installing ipxe and ipxe-qemu. What distro provided iPXE file can we
use?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86: report use of PCID together with reporting XPTI status
On Mon, Jul 16, 2018 at 10:45:15AM -0600, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -288,6 +288,12 @@ int pv_domain_initialise(struct domain *
> return rc;
> }
>
> +bool __init xpti_pcid_enabled(void)
> +{
> +return use_invpcid && cpu_has_pcid &&
> + (opt_pcid == PCID_ALL || opt_pcid == PCID_XPTI);
> +}
> +
> static void _toggle_guest_pt(struct vcpu *v)
> {
> const struct domain *d = v->domain;
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -256,9 +256,10 @@ static void __init print_details(enum in
> boot_cpu_has(X86_FEATURE_SC_RSB_HVM) ? " RSB" : "",
> opt_eager_fpu ? " EAGER_FPU" :
> "");
>
> -printk(" XPTI (64-bit PV only): Dom0 %s, DomU %s\n",
> +printk(" XPTI (64-bit PV only): Dom0 %s, DomU %s (with%s PCID)\n",
Do you ever foresee wanting to add another flag in here? It might be
better to just have "with: %s" and do xpti_pcid_enabled ? "PCID" : "" if
you do. If not then this seems like a good addition to me and is
definitely welcome to folks wanting to know if they're using PCID.
Reviewed-by: Doug Goldstein
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation: add SLES 11 SP4 dockerfile
On Tue, Jul 17, 2018 at 09:03:05PM +0100, Wei Liu wrote: > Signed-off-by: Wei Liu Awesome work Wei. Thanks for taking the time and effort to get this done. I'll defer to Jan to confirm that this will hopefully be an effective stand in but you've got my Reviewed-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation/build: update stretck-i386 dockerfile
On Thu, Jul 12, 2018 at 02:33:42PM -0500, Doug Goldstein wrote: > On Thu, Jul 12, 2018 at 05:31:27PM +0100, Wei Liu wrote: > > We don't need to specify /bin/bash in the entry point rune, otherwise > > non-interactive invocation of the container would fail with something > > like: > > > > + C=debian:stretch-i386 > > + export CONTAINER=registry.gitlab.com/xen-project/xen/debian:stretch-i386 > > + CONTAINER=registry.gitlab.com/xen-project/xen/debian:stretch-i386 > > + cd /local/work/COMMITTER/xen-32.git > > + git fetch origin > > + con git reset --hard origin/staging > > *** Ensuring registry.gitlab.com/xen-project/xen/debian:stretch-i386 is up > > to date > > *** Launching container ... > > /usr/bin/git: /usr/bin/git: cannot execute binary file > > > > While at it, use shorthand "linux32". > > > > Signed-off-by: Wei Liu > > --- > > Acked-by: Doug Goldstein Oh I forgot to note that there's a typo in the subject but that can just be fixed while committing. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation/build: update stretck-i386 dockerfile
On Thu, Jul 12, 2018 at 05:31:27PM +0100, Wei Liu wrote: > We don't need to specify /bin/bash in the entry point rune, otherwise > non-interactive invocation of the container would fail with something > like: > > + C=debian:stretch-i386 > + export CONTAINER=registry.gitlab.com/xen-project/xen/debian:stretch-i386 > + CONTAINER=registry.gitlab.com/xen-project/xen/debian:stretch-i386 > + cd /local/work/COMMITTER/xen-32.git > + git fetch origin > + con git reset --hard origin/staging > *** Ensuring registry.gitlab.com/xen-project/xen/debian:stretch-i386 is up to > date > *** Launching container ... > /usr/bin/git: /usr/bin/git: cannot execute binary file > > While at it, use shorthand "linux32". > > Signed-off-by: Wei Liu > --- Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] automation/build: build ovmf
On Wed, Jul 11, 2018 at 02:16:16PM +0100, Wei Liu wrote: > Install nasm and build ovmf with gcc on x86. > > Signed-off-by: Wei Liu > --- Acked-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] scripts: add helper script to use Docker containers
This adds a script that can be used to do builds easily within the
defined containers under the automation directory. These containers live
in the public GitLab registry under the xen-project namespace. The
script can be executed a number of ways but the default is to drop you
at a bash shell within a Debian Stretch container at the top level of
the source tree.
Signed-off-by: Doug Goldstein
---
A few folks have asked about this so I'm CCing folks directly. I'm
completely game for changing anything that makes this easier for folks
to use. This is primarily geared as a developer/maintainer tool but
its also good for folks just starting out with Xen and not having
all the dependencies installed.
CC: Andrew Cooper
CC: George Dunlap
CC: Ian Jackson
CC: Stefano Stabellini
CC: Wei Liu
---
automation/build/README.md | 53 ---
automation/scripts/containerize | 93 ++-
2 files changed, 138 insertions(+), 8 deletions(-)
create mode 100755 automation/scripts/containerize
diff --git a/automation/build/README.md b/automation/build/README.md
index 0206d57..be4526c 100644
--- a/automation/build/README.md
+++ b/automation/build/README.md
@@ -5,9 +5,12 @@ These Docker containers should make it possible to build Xen in
any of the available environments on any system that supports
running Docker. They are organized by distro and tagged with
the version of that distro. They are available from the GitLab
-Container Registry under the Xen project at:
+Container Registry under the Xen project at the [registry] and
+can be pulled with Docker from the following path:
-registry.gitlab.com/xen-project/xen/DISTRO:VERSION
+```
+docker pull registry.gitlab.com/xen-project/xen/DISTRO:VERSION
+```
To see the list of available containers run `make` in this
directory. You will have to replace the `/` with a `:` to use
@@ -19,16 +22,50 @@ Building Xen
From the top level of the source tree it should be possible to
run the following:
-docker run --rm -it -v $(PWD):/build -u $(id -u) -e CC=gcc $(CONTAINER) make
+```
+./automation/scripts/containerize make
+```
-There are other modifications that can be made but this will run
-the `make` command inside the specified container. It will use your
-currently checked out source tree to build with, ensure that file
-permissions remain consistent and clean up after itself.
+Which will cause the top level `make` to execute within the default
+container, which is currently defined as Debian Stretch. Any arguments
+specified to the script will be executed within the container from
+the default shell.
+
+There are several environment variables which the containerize script
+understands.
+
+- CONTAINER: This overrides the container to use. For CentOS 7.2, use:
+
+ ```
+ CONTAINER=centos72 ./automation/scripts/containerize make
+ ```
+
+- WORKDIR: This overrides the path that will be available under the
+ `/build` directory in the container, which is the default path.
+
+ ```
+ WORKDIR=/some/other/path ./automation/scripts/containerize ls
+ ```
+
+- XEN_CONFIG_EXPERT: If this is defined in your shell it will be
+ automatically passed through to the container.
+
+- CONTAINER_NAME: By default the container name is set based on the
+ container itself so that its easy to attach other terminals to your
+ container. This however prevents you from running multiple containers
+ of the same version. Override the name value to cause it to name
+ the container differently on start.
+
+- EXTRA_CONTAINER_ARGS: Allows you to pass extra arguments to Docker
+ when starting the container.
Building a container
There is a makefile to make this process easier. You should be
able to run `make DISTRO/VERSION` to have Docker build the container
-for you.
+for you. If you define the `PUSH` environment variable when running the
+former `make` command, it will push the container to the [registry] if
+you have access to do so.
+
+[registry]: https://gitlab.com/xen-project/xen/container_registry
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
new file mode 100755
index 000..7253617
--- /dev/null
+++ b/automation/scripts/containerize
@@ -0,0 +1,93 @@
+#!/bin/bash
+
+einfo() {
+ echo "$*" >&2
+}
+
+die() {
+echo "$*" >&2
+exit 1
+}
+
+#
+# The caller is expected to override the CONTAINER environment
+# variable with the container they wish to launch.
+#
+BASE="registry.gitlab.com/xen-project/xen"
+case "_${CONTAINER}" in
+_centos72) CONTAINER="${BASE}/centos:7.2" ;;
+_trusty) CONTAINER="${BASE}/ubuntu:trusty" ;;
+_xenial) CONTAINER="${BASE}/ubuntu:xenial" ;;
+_jessie) CONTAINER="${BASE}/debian:jessie" ;;
+_stretch|_) CONTAINER="${BASE}/debian:stretch" ;;
+esac
+
+# get our container name and version
+containid=${CONTAINER%:*}
+containver=${CO
Re: [Xen-devel] [PATCH] automation: fix builds with clang
On Tue, Jul 10, 2018 at 05:58:58PM -0500, Doug Goldstein wrote: Without this patch: https://gitlab.com/xen-project/xen/pipelines/25489605 With this patch: https://gitlab.com/cardoe/xen/pipelines/25512404 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] automation: fix builds with clang
a75703b2f0f585a2fc6a7bcdb7d16a61bcf5e6b0 unconditionally enabled
building of rombios and stubdoms but unfortunately these two pieces do
not build successfully with clang. rombios unconditionally depends on
the build of iPXE and upstream iPXE does not support building with
clang. Similiarly the build of the stubdoms depends on the build of
newlib which does not support being built with clang.
Signed-off-by: Doug Goldstein
---
automation/scripts/build | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/automation/scripts/build b/automation/scripts/build
index b9e4c1e329..8bbca15a51 100755
--- a/automation/scripts/build
+++ b/automation/scripts/build
@@ -13,9 +13,13 @@ fi
cfgargs=()
cfgargs+=("--enable-docs")
-# SeaBIOS cannot be built with clang
if [[ "${CC}" == "clang" ]]; then
+# SeaBIOS cannot be built with clang
cfgargs+=("--with-system-seabios=/usr/share/seabios/bios.bin")
+# iPXE cannot be built with clang so we cannot build rombios
+cfgargs+=("--disable-rombios")
+# newlib cannot be built with clang so we cannot build stubdoms
+cfgargs+=("--disable-stubdom")
fi
if [[ "${XEN_TARGET_ARCH}" == "arm64" || "${XEN_TARGET_ARCH}" == "arm32" ]];
then
--
2.16.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 4/4] automation: build more stuff on x86 with docker
On Mon, Jul 09, 2018 at 04:32:16PM +0100, Wei Liu wrote: > Signed-off-by: Wei Liu > --- > Untested > --- Reviewed-by: Doug Goldstein I'll test this once we hammer out if we're pulling in texinfo or not. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/4] automation: introduce stretch-i386.dockerfile
On Mon, Jul 09, 2018 at 04:32:15PM +0100, Wei Liu wrote: > Signed-off-by: Wei Liu > > diff --git a/automation/build/debian/stretch-i386.dockerfile > b/automation/build/debian/stretch-i386.dockerfile > new file mode 100644 > index 00..add2204535 > --- /dev/null > +++ b/automation/build/debian/stretch-i386.dockerfile > +texinfo \ If https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg00810.html gets accepted then we need to drop this. Otherwise looks good. Reviewed-by: Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/4] automation: install texinfo
On Mon, Jul 09, 2018 at 04:32:13PM +0100, Wei Liu wrote: > Stubdom's dependency newlib needs it. > > Signed-off-by: Wei Liu Could we consider <20180709170546.4102-1-car...@cardoe.com> instead? https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg00810.html ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] stubdom: disable newlib's need for texinfo
newlib has a hardcoded dependency on texinfo, which in turn means that Xen has this dependency when building the stub domains. The files that newlib generates are never used or exposed by the Xen build system so its really a wasted effort to require a heavy (size wise) package for the build of something that's thrown away. Instead of adding it as a requirement this patches out the code path in newlib that uses it so that the files are never generated. Signed-off-by: Doug Goldstein --- stubdom/Makefile | 1 + stubdom/newlib-disable-texinfo.patch | 13 + 2 files changed, 14 insertions(+) create mode 100644 stubdom/newlib-disable-texinfo.patch diff --git a/stubdom/Makefile b/stubdom/Makefile index 34bd9e238b..8cf7131c6a 100644 --- a/stubdom/Makefile +++ b/stubdom/Makefile @@ -87,6 +87,7 @@ newlib-$(NEWLIB_VERSION): newlib-$(NEWLIB_VERSION).tar.gz patch -d $@ -p0 < newlib.patch patch -d $@ -p0 < newlib-chk.patch patch -d $@ -p1 < newlib-stdint-size_max-fix-from-1.17.0.patch + patch -d $@ -p1 < newlib-disable-texinfo.patch find $@ -type f | xargs perl -i.bak \ -pe 's/\b_(tzname|daylight|timezone)\b/$$1/g' touch $@ diff --git a/stubdom/newlib-disable-texinfo.patch b/stubdom/newlib-disable-texinfo.patch new file mode 100644 index 00..5ce2e45caa --- /dev/null +++ b/stubdom/newlib-disable-texinfo.patch @@ -0,0 +1,13 @@ +--- a/etc/Makefile.in 2007-03-27 13:09:32.0 -0500 b/etc/Makefile.in 2018-07-09 11:08:50.294183081 -0500 +@@ -63,8 +63,8 @@ + PDFFILES = standards.pdf configure.pdf + HTMLFILES = standards.html configure.html + +-all: info +-install: install-info ++all: ++install: + + uninstall: + -- 2.16.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
