Re: Listing the tools required for Xen development/testing on x86 and Arm by the community

[Ayan Kumar Halder <ayankuma@xxxxxxx>]

Hi Roger,

On 02/06/2023 16:24, Roger Pau Monné wrote:
> On Fri, Jun 02, 2023 at 02:46:03PM +0100, Ayan Kumar Halder wrote:
> > Hi Roger,
> >
> > On 02/06/2023 12:43, Roger Pau Monné wrote:
> > > On Fri, Jun 02, 2023 at 09:48:48AM +0100, Ayan Kumar Halder wrote:
> > > > Hi Xen developers,
> > > >
> > > > We are trying to better document xen project development processes and
> > > > related tools. At present, we are targeting **x86 and Arm** only.
> > > >
> > > > These tools range from bug/change request tracking means, compilers, infra,
> > > > editors, code-review tools, etc which is connected in some way to the Xen
> > > > development and is being currently used by xen-devel community.
> > > What is the end goal of this?
> > We are trying to do an initial assesment of the requirements for Xen
> > functional safety.
> >
> > As a first step, I am trying to make a list tools which are in someways
> > related to Xen development/testing/deployment.
> >
> > > I'm kind of unsure why do you care about which editor I use to
> > > generate my code, that's up to the developer.
> > I agree that editor, email-clients are something that are an individual
> > developer's choice.
> >
> > However as it is related to Xen development, we want to atleast put down
> > some of the commonly used tools.
> >
> > At a later state when (and if) we go through the list with a safety
> > assessor, we might prune some of these items.
> I have very little idea about what's required for a safety assessor,
> sorry.
Same here :)
> Will this have an impact on what tools are allowed to be used when
> working with certain parts of Xen? (the safety certifiable parts I
> would assume)
At the moment, I am not very sure.

At the least, our first step is to gather the list of existing tools.

> > > > I appreciate if you can let me know anything I missed or mistaken and the
> > > > version currently being used (for some of the tools).
> > > >
> > > >
> > > > 1. Code management portal - xenbits (https://xenbits.xenproject.org), gitlab
> > > > (https://gitlab.com/xen-project/xen)
> > > >
> > > > 2. Project description - wiki.xenproject.org
> > > >
> > > > 3. Project management - gitlab
> > > >
> > > > 4. Code review - text based email clients (mutt, thunderbird), git-email, b4
> > > >
> > > > 5. Text Editors such as vim, emacs
> > > >
> > > > 6. Code review history - xen-devel mail archives
> > > >
> > > > 7. Code revision management - git
> > > >
> > > > 8. Xen coding language - C89, C99, Kconfig
> > > assembly (gas), python, perl, shell, Makefile, bison, flex, ocaml,
> > > go...
> > >
> > > Likely more that I've missed.
> > Ack
> > > > 9. Testing tools for Arm64 in gitlab CI
> > > >
> > > > compiler - gcc-9.3.0 (Alpine 3.12)) (most commonly used version)
> > > >
> > > > binutils - GNU Binutils for Debian) 2.38.9
> > > >
> > > > emulator/hw - qemu-system-aarch64-6.0.0, qemuarm64 6.2.0 (From yocto, poky
> > > > disto - 4.0.5), zcu102 (**need the uboot, TF-A versions **)
> > > >
> > > > dom0/domU kernel - kernel-5.19.0
> > > >
> > > > rootfs - alpine-3.12-arm64-rootfs
> > > >
> > > > firmware - U-Boot 2022.10
> > > >
> > > > 10. Testing tools for Arm in gitlab CI
> > > >
> > > > compiler - arm-poky-linux-gnueabi-gcc (GCC) 11.3.0, arm-linux-gnueabihf-gcc
> > > > (Debian 12.2.0-14) 12.2.0 (most commonly used versions)
> > > >
> > > > emulator/hw - qemu-system-arm 6.2.0 (From yocto, poky disto - 4.0.5)
> > > >
> > > > dom0/domU kernel - kernel-5.15.72 (from Yocto), Kernel-5.10.0-22 (from
> > > > Debian)
> > > >
> > > > rootfs - alpine-minirootfs-3.15.1-armhf.tar.gz
> > > >
> > > > firmware - U-Boot 2022.10
> > > >
> > > > 11. Testing tools for x86
> > > >
> > > > compiler - gcc-9.3.0 (Alpine Linux 9.3.0), gcc (Debian 12.2.0-14) 12.2.0,
> > > > clang (from Debian) (most commonly used version)
> > > >
> > > > binutils - GNU ld (GNU Binutils for Debian) 2.40)
> > > >
> > > > emulator/hardware - Qubes HW (**need details regarding machine, firmware,
> > > > etc**) , qemu 6.2.0 (From yocto, poky distro - 4.0.5)
> > > >
> > > > dom0/domU kernel - kernel 6.1.19
> > > >
> > > > rootfs - alpine-3.12-rootfs
> > > >
> > > > firmware - BIOS Dasharo (coreboot+UEFI) v1.1.1 02/22/2023 , EFI v2.70 by EDK
> > > > II , SMBIOS 3.3.0 , SeaBIOS (version rel-1.16.2-0-gea1b7a0-Xen), GRUB
> > > > 2.06~rc1
> > > I do use an LLVM based toolstack, so that's usually latest LLVM import
> > > on FreeBSD.  We do also test this on the cirrus-ci, see:
> > >
> > > https://github.com/royger/xen/runs/5334480206
> > Thanks, this is interesting info.
> >
> > For the moment, I am ignoring the downstream forks of Xen.
> That's not a fork of Xen, just plain Xen hosted on my personal github
> repo.
Ok
> > I am only considering the tools used by the upstream Xen and the associated
> > CI/CD.
> Gitlab CI does test with LLVM toolchain also.
>
> osstest does test FreeBSD guests, but no FreeBSD dom0.
Ok
> > > I_n any case I think the scope to some of the questions is unknown,
> > > it's not feasible to expect to list every possible combination of
> > > Linux versions vs Xen version vs whatever guests versions a given
> > > developer might be running.
> > I agree . That is the reason I am picking up the compiler, linux, binutils,
> > firmware, etc versions from our gitlab CI.
> >
> > It also acts as a proof that we are testing Xen against a known set of
> > compiler, linux versions, etc.
> OK, so the question is not what every developers uses, but you trying
> to narrow down the scope to a specific environment?
Yes, I am trying to do 3 things here :-

1. Gather the most commonly used developer tools - For eg vim, emacs, 
mutt, thunderbird
2. Gather the current tools used in any existing upstream Xen testing - 
For eg gitlab tests, OSS tests, XTF, etc.
Here, I am particularly interested in the libraries, compilers, 
binutils, kernel, hardware/emulator, firmware and their respective versions.
3. Gather all the dependencies for Xen - For eg C89, C99, python, Asm, 
OS packages mentioned in README (as Christopher pointed out).
> Maybe what you want to do is create a specific container in the Gitlab
> CI that has the specific tools versions you care about from a safety
> certify angle.
Yes, that might be a possible approach.

- Ayan

> Regards, Roger.