xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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

  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).