From: Lars Kurth <firstname.lastname@example.org>
To: Andrew Cooper <email@example.com>
Cc: Bobby Eshleman <firstname.lastname@example.org>,
Stefano Stabellini <email@example.com>,
Julien Grall <firstname.lastname@example.org>, Wei Liu <email@example.com>,
Konrad Rzeszutek Wilk <firstname.lastname@example.org>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Ian Jackson <email@example.com>,
Bobby Eshleman <firstname.lastname@example.org>,
Dan Robertson <email@example.com>,
Alistair Francis <firstname.lastname@example.org>,
Subject: Re: [Xen-devel] [RFC XEN PATCH 00/23] xen: beginning support for RISC-V
Date: Wed, 22 Jan 2020 16:27:39 +0000 [thread overview]
Message-ID: <052081D4-2F9F-401A-A6F6-8A9CDC1069AC@xenproject.org> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 4433 bytes --]
> On 22 Jan 2020, at 14:57, Andrew Cooper <email@example.com> 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
>> 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
>> 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?
> 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.
I totally agree with what Andy says.
You should also leverage the developer summit: see https://events.linuxfoundation.org/xen-summit/program/cfp/ <https://events.linuxfoundation.org/xen-summit/program/cfp/>
CfP closes March 6th. Design sessions can be submitted afterwards
Community calls may also be a good option to deal with specific issues / questions, e.g. around compile support in the CI, etc.
[-- Attachment #1.2: Type: text/html, Size: 25332 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
Xen-devel mailing list
next prev parent reply other threads:[~2020-01-22 16:27 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 [this message]
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
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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).