[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/3] Initial support for Power



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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.