From: Alistair Francis <Alistair.Francis@wdc.com>
To: "bobbyeshleman@gmail.com" <bobbyeshleman@gmail.com>,
"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "dan@dlrobertson.com" <dan@dlrobertson.com>,
"julien@xen.org" <julien@xen.org>, "wl@xen.org" <wl@xen.org>,
"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
"George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>,
"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
"bobby.eshleman@starlab.io" <bobby.eshleman@starlab.io>,
"sstabellini@kernel.org" <sstabellini@kernel.org>
Subject: Re: [Xen-devel] [RFC XEN PATCH 00/23] xen: beginning support for RISC-V
Date: Thu, 23 Jan 2020 08:25:11 +0000 [thread overview]
Message-ID: <bad6fccb97ae5cf03d2845aa77c5e1af61be48bc.camel@wdc.com> (raw)
In-Reply-To: <f8ca4739-83c7-5829-4663-b1e5796e6490@citrix.com>
On Wed, 2020-01-22 at 14:57 +0000, Andrew Cooper wrote:
> On 22/01/2020 01:58, Bobby Eshleman wrote:
> > Hey everybody,
> >
> > This is an RFC patchset for the very beginnings of adding RISC-V
> > support
> > to Xen. This RFC is really just to start a dialogue about
> > supporting
> > RISC-V and align with the Xen project and community before going
> > further. For that reason, it is very rough and very incomplete.
> >
> > My name is Bobby Eshleman, I'm a software engineer at
> > Star Lab / Wind River on the ARM team, mostly having worked in the
> > Linux
> > kernel. I've also been involved a good amount with Xen on ARM
> > here,
> > mostly dealing with tooling, deployment, and testing. A lot of
> > this
> > patchset is heavily inspired by the Xen/ARM source code
> > (particularly
> > the early setup up code).
> >
> > Currently, this patchset really only sets up virtual memory for Xen
> > and
> > initializes UART to enable print output. None of RISC-V's
> > virtualization support has been implemented yet, although that is
> > the
> > next road to start going down. Many functions only contain dummy
> > implementations. Many shortcuts have been taken and TODO's have
> > been
> > left accordingly. It is very, very rough. Be forewarned: you are
> > quite
> > likely to see some ungainly code here (despite my efforts to clean
> > it up
> > before sending this patchset out). My intent with this RFC is to
> > align
> > early and gauge interest, as opposed to presenting a totally
> > complete
> > patchset.
> >
> > Because the ARM and RISC-V use cases will likely bear resemblance,
> > the
> > RISC-V port should probably respect the design considerations that
> > have
> > been laid out and respected by Xen on ARM for dom0less, safety
> > certification, etc... My inclination has been to initially target
> > or
> > prioritize dom0less (without excluding dom0full) and use the ARM
> > dom0less implementation as a model to follow. I'd love feedback on
> > this
> > point and on how the Xen project might envision a RISC-V
> > implementation.
> >
> > This patchset has _some_ code for future support for 32-bit, but
> > currently my focus is on 64-bit.
> >
> > Again, this is a very, very rough and totally incomplete
> > patchset. My
> > goal here is just to gauge community interest, begin discussing
> > what Xen
> > on RISC-V may look like, receive feedback, and see if I'm heading
> > in the
> > right direction.
> >
> > My big questions are:
> > Does the Xen project have interest in RISC-V?
>
> There is very large downstream interest in RISC-V. So a definite
> yes.
>
> > What can be done to make the RISC-V port as upstreamable as
> > possible?
> > Any major pitfalls?
> >
> > It would be great to hear all of your feedback.
>
> Both RISC-V and Power9 are frequently requested things, and both
> suffer
> from the fact that, while we as a community would like them, the
> upstream intersection of "people who know Xen" and "people who know
> enough arch $X to do an initial port" is 0.
>
> This series clearly demonstrates a change in the status quo, and I
> think
> a lot of people will be happy.
>
> To get RISC-V to being fully supported, we will ultimately need to
> get
> hardware into the CI system, and an easy way for developers to test
> changes. Do you have any thoughts on production RISC-V hardware
> (ideally server form factor) for the CI system, and/or dev boards
> which
> might be available fairly cheaply?
AFAIK this is awhile off. The Hypervisor spec is still in a draft state
(expecting to be frozen this year) so right now QEMU is the only
option.
Alistair
>
> How much time do you have to put towards the port? Is this something
> in
> your free time, or something you are doing as part of work?
> Ultimately,
> we are going to need to increase the level of RISC-V knowledge in the
> community to maintain things in the future.
>
> Other than that, very RFC series are entirely fine. A good first
> step
> would be simply to get the build working, and get some kind of
> cross-compile build in CI, to make sure that we don't clobber the
> RISC-V
> build with common or other-arch changes.
>
> I hope this helps.
>
> ~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2020-01-23 8:31 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-22 1:58 [Xen-devel] [RFC XEN PATCH 00/23] xen: beginning support for RISC-V Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 01/23] HACK: OE Build changes Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 02/23] HACK: Makefile: Don't build Xen tools Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 03/23] riscv: makefiles and Kconfig Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 04/23] riscv: header files Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 05/23] riscv: early setup code Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 06/23] riscv: Add riscv to tools/libxc header files Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 07/23] riscv: Add asm-offsets.c Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 08/23] riscv: Add delay.c Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 09/23] riscv: Add domain.c Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 10/23] riscv: Add domctl.c Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 11/23] riscv: Add guestcopy.c Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 12/23] riscv: Add time.c Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 13/23] riscv: Add smp.c Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 14/23] riscv: Add shutdown.c Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 15/23] riscv: Add traps.c Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 16/23] riscv: Add irq.c Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 17/23] riscv: Add vm_event.c Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 18/23] riscv: Add p2m.c Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 19/23] riscv: Add the lib directory Bobby Eshleman
2020-06-22 11:38 ` Jan Beulich
2020-06-30 1:55 ` Bobby Eshleman
2020-01-22 1:58 ` [Xen-devel] [RFC XEN PATCH 20/23] riscv: Add smpboot.c Bobby Eshleman
2020-01-22 1:59 ` [Xen-devel] [RFC XEN PATCH 21/23] riscv: Add percpu.c Bobby Eshleman
2020-01-22 1:59 ` [Xen-devel] [RFC XEN PATCH 22/23] riscv: Add sysctl.c Bobby Eshleman
2020-06-22 11:43 ` Jan Beulich
2020-06-30 1:51 ` Bobby Eshleman
2020-01-22 1:59 ` [Xen-devel] [RFC XEN PATCH 23/23] riscv: Add iommu.c Bobby Eshleman
2020-01-22 14:57 ` [Xen-devel] [RFC XEN PATCH 00/23] xen: beginning support for RISC-V Andrew Cooper
2020-01-22 16:27 ` Lars Kurth
2020-01-23 5:31 ` Bobby Eshleman
2020-01-23 23:44 ` Lars Kurth
2020-01-25 1:59 ` Bobby Eshleman
2020-01-22 21:05 ` Stefano Stabellini
[not found] ` <20200123044527.GA5583@bobbye-pc>
2020-01-23 5:13 ` Bobby Eshleman
2020-01-23 5:19 ` Bobby Eshleman
2020-01-23 16:02 ` Andrew Cooper
2020-01-25 1:58 ` Bobby Eshleman
2020-01-23 8:25 ` Alistair Francis [this message]
2020-01-24 13:41 ` Andrew Cooper
2020-01-25 3:26 ` Bobby Eshleman
2020-01-25 17:11 ` Andrew Cooper
2020-01-28 3:37 ` Bobby Eshleman
2020-06-16 1:03 ` Stefano Stabellini
2020-06-16 1:08 ` Roman Shaposhnik
2020-06-16 1:10 ` Alistair Francis
2020-06-16 3:51 ` Bobby Eshleman
2020-06-16 20:16 ` Stefano Stabellini
2020-06-30 1:50 ` Bobby Eshleman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bad6fccb97ae5cf03d2845aa77c5e1af61be48bc.camel@wdc.com \
--to=alistair.francis@wdc.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=bobby.eshleman@starlab.io \
--cc=bobbyeshleman@gmail.com \
--cc=dan@dlrobertson.com \
--cc=ian.jackson@eu.citrix.com \
--cc=julien@xen.org \
--cc=konrad.wilk@oracle.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).