| Message ID | cover.1686148363.git.shawn@anastas.io (mailing list archive) |
|---|---|
| Headers | show |
| Series | Initial support for Power | expand |
On 07/06/2023 4:06 pm, Shawn Anastasio wrote: > Hello all, > > This patch series adds support for building a minimal image > (head.o-only) for Power ISA 2.07B+ (POWER8+) systems. The first patch > boots to an infinite loop and the second adds early serial console > support on pseries VMs, with bare metal support planned next. > > Since Xen previously had support for a much older version of the ISA in > version 3.2.3, we were able to carry over some headers and support > routines from that version. Unlike that initial port though, this effort > focuses solely on POWER8+ CPUs that are capable of running in Little > Endian mode. > > With an appropriate powerpc64le-linux-gnu cross-toolchain, the minimal > image can be built with: > > $ make XEN_TARGET_ARCH=ppc64 -C xen openpower_defconfig > $ make XEN_TARGET_ARCH=ppc64 SUBSYSTEMS=xen -C xen TARGET=ppc64/head.o > > The resulting head.o can then be booted in a standard QEMU/pseries VM: > > $ qemu-system-ppc64 -M pseries-5.2 -m 256M -kernel xen/ppc64/head.o \ > -vga none -serial mon:stdio -nographic > > Thanks, > Shawn > > Shawn Anastasio (3): > xen: Add files needed for minimal Power build > xen/ppc: Implement early serial printk on PaPR/pseries > maintainers: Add PPC64 maintainer Oh wow - this is a surprise, but certainly a good one. We've recently done just a similar exercise with RISCV64, starting with getting cross-compilation and a basic smoke test into our CI. We use gitlab CI, and one example is https://gitlab.com/xen-project/xen/-/pipelines/889871648 (search for riscv64 in amongst all the x86 and ARM). The configuration is all in tree, in the automation/ directory. Relevant files to copy/tweak are: automation/build/archlinux/current-riscv64.dockerfile (x86 cross compile container) automation/scripts/qemu-smoke-riscv64.sh (smoke test script) automation/gitlab-ci/{build,test}.yaml (wire the jobs up) The smoke test looks on stdout for "All set up" which can be any string put out via earlyprintk. If you look around in the Xen tree at bb62c25e3e5c and take the makefile override's in particular, you should be able to get `make -C xen build` work without any magic TARGET= overrides, and without most of the headers you've added in patch 1. The trick is to have a head.S which doesn't include any files (except the config.h it gets implicitly). We're still trying to do some re-arranging to the common / arch split to remove unnecessary boilerplate. Having a set of PPC headers too will make it easier to spot the rough edges in the current boundary. Looking to the future, where could XenProject get some real hardware to put into our CI systems? We'd want to do that in due course. I see you've nominated yourself as maintainer, which is of course fine. How much time do you have to put towards this? It is some part of a full time job, or just your own free time? Do you have any suggested reading for those of us who are invariably going to need to learn some of the CPU/platform/architecture details, but aren't really PPC-literate right now? Thanks, and welcome. ~Andrew
On Wed Jun 7, 2023 at 1:07 PM CDT, Andrew Cooper wrote: > Oh wow - this is a surprise, but certainly a good one. I'm glad to hear that! > We've recently done just a similar exercise with RISCV64, starting with > getting cross-compilation and a basic smoke test into our CI. I see. I used the initial RISC-V patch as a model for patch 1, though I didn't realize that the TARGET= override were unnecessary for getting a minimal image building. > We use gitlab CI, and one example is > https://gitlab.com/xen-project/xen/-/pipelines/889871648 (search for > riscv64 in amongst all the x86 and ARM). > > The configuration is all in tree, in the automation/ directory. > Relevant files to copy/tweak are: > > automation/build/archlinux/current-riscv64.dockerfile (x86 cross compile > container) > automation/scripts/qemu-smoke-riscv64.sh (smoke test script) > automation/gitlab-ci/{build,test}.yaml (wire the jobs up) > > The smoke test looks on stdout for "All set up" which can be any string > put out via earlyprintk. Thanks for the pointer -- I'll use this as a model to implement a similar smoke test for PPC64. > If you look around in the Xen tree at bb62c25e3e5c and take the makefile > override's in particular, you should be able to get `make -C xen build` > work without any magic TARGET= overrides, and without most of the > headers you've added in patch 1. The trick is to have a head.S which > doesn't include any files (except the config.h it gets implicitly). Perfect. I'll start work on a v2 without the TARGET= overrides and without the headers in patch #1. > We're still trying to do some re-arranging to the common / arch split to > remove unnecessary boilerplate. Having a set of PPC headers too will > make it easier to spot the rough edges in the current boundary. Great. I've been using arch/arm and arch/riscv as models for which headers to define (as well as the build errors that inevitably pop up when including xen/lib.h or similar). Is this a reasonable approach for now? > Looking to the future, where could XenProject get some real hardware to > put into our CI systems? We'd want to do that in due course. As an employee of Raptor Engineering, my recommendation for an OpenPOWER system would definitely be the Talos II or Blackbird families from Raptor Computing Systems: https://www.raptorcs.com/ :) > I see you've nominated yourself as maintainer, which is of course fine. > How much time do you have to put towards this? It is some part of a > full time job, or just your own free time? I'm currently working on the port full-time for Raptor Engineering. > Do you have any suggested reading for those of us who are invariably > going to need to learn some of the CPU/platform/architecture details, > but aren't really PPC-literate right now? We have a pretty extensive library of documentation covering the ISA as well as CPU and platform details available here: https://wiki.raptorcs.com/wiki/Category:Documentation > Thanks, and welcome. Thanks! Shawn
On 07/06/2023 8:01 pm, Shawn Anastasio wrote: >> If you look around in the Xen tree at bb62c25e3e5c and take the makefile >> override's in particular, you should be able to get `make -C xen build` >> work without any magic TARGET= overrides, and without most of the >> headers you've added in patch 1. The trick is to have a head.S which >> doesn't include any files (except the config.h it gets implicitly). > Perfect. I'll start work on a v2 without the TARGET= overrides and > without the headers in patch #1. Ok, in which case you probably want a first patch series doing: 1) New docker container (only - this wants to be taken early and set up in CI) 2) one-or-more initial build system + head.S infinite loop patch. Probably the maintainer patch too. 3) Wiring the build(s) into build.yaml You'll want to join the https://gitlab.com/xen-project/ and I can set you up with a place to run the full CI (we have a reasonably custom setup which the communal runners don't like). You may also want to hang out on oftc.org #xendevel and/or the matrix bridge thereof. Then a second patch series doing early printk, and adding the smoke test script and wiring it into test.yaml. ~Andrew
On Wed Jun 7, 2023 at 2:30 PM CDT, Andrew Cooper wrote: > Ok, in which case you probably want a first patch series doing: > > 1) New docker container (only - this wants to be taken early and set up > in CI) > 2) one-or-more initial build system + head.S infinite loop patch. > Probably the maintainer patch too. > 3) Wiring the build(s) into build.yaml > > You'll want to join the https://gitlab.com/xen-project/ and I can set > you up with a place to run the full CI (we have a reasonably custom > setup which the communal runners don't like). You may also want to hang > out on oftc.org #xendevel and/or the matrix bridge thereof. > > Then a second patch series doing early printk, and adding the smoke test > script and wiring it into test.yaml. Sounds good. I've gone ahead and requested access to that GitLab organization and will get to work on a series doing the things you've requested. P.S. It seems mail from my server is getting rejected by your server, so I'm unable to respond to you directly. Once I have access to my corporate email this should be resolved, but until then I'll reach out to you from a personal email address. Thanks.