From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.2 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, MIME_HTML_MOSTLY,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0ABAC2D0DB for ; Wed, 22 Jan 2020 16:27:59 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A64B22253D for ; Wed, 22 Jan 2020 16:27:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="c32wD03h" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A64B22253D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iuIr3-0002U4-7W; Wed, 22 Jan 2020 16:27:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iuIr1-0002Tv-FY for xen-devel@lists.xenproject.org; Wed, 22 Jan 2020 16:27:43 +0000 X-Inumbo-ID: 1cb60cbe-3d34-11ea-8e9a-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1cb60cbe-3d34-11ea-8e9a-bc764e2007e4; Wed, 22 Jan 2020 16:27:42 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id b19so7448162wmj.4 for ; Wed, 22 Jan 2020 08:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=89Y9pzoD1ZWxrugMvroXmDP8OCW1Jlz3uHHb5BhPbJk=; b=c32wD03hP4Myy7nehtiy3tprL8nmHa6w3w9LOt+svfujvjyfXVWOPGYGk7MVce7cBT WipJaT+qAl0TK/APVUgmQePScZwi4vAtO/mNTLqo6nEuJ9LuB9XE7F4ag/YBXrMFV1Su PJdKMm1OEKs/B0x2D8VfQZjeSy7VwNZAkBsTgwKcC9S9MXGmvZlbsnH7pgG495JmIZG9 1lwaXIRKTnoc4G4GZd844PEcQseahlA5axuXjj83k6S0oSnPt8CRUicIUPK6flBkob1H QhODpGctBfn3a51aEMNCtHLd2j8RHxJbDFWarirLbRKPkWrQ/uchYxjEeMGHYzGfbct0 3ufg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=89Y9pzoD1ZWxrugMvroXmDP8OCW1Jlz3uHHb5BhPbJk=; b=CQ5p2ooaYPrDLmNOqAY2c/tNEIIcgJczMQmlLr3uI7utESPj21oJePd1agMSFzhXC/ m25g8aUOrg15q6SkpUCGq9G/Syjk97o/py5YcqqLgimSPAb2+kwxRoXZs1fuLmf9zzub uH4+uw9wVvOU4EfEBy6Zf4Dnnq/DQ1kZ+Lsuq+AGsNFvFsyDUTYZT1DzaGGW/sepnEzP CUGtUh/KBfg4WrPMSIMdCnMbupkRT4tVccDG+jUsjYfruQ12ZPicB3m1Lbo11vaekOMk J1jyr2/HWn1HsK6AR6gDIMCNGcsZrAeo/oJbVk/BDdj4FBSMjOuMIUL2sylhkxx2rmka mbVw== X-Gm-Message-State: APjAAAWhgB2ox7QT4YBEag9Vv9yX6Y9S0uuHJArq+vFII+bI0QrZL1tD 89JEOYV1zIYWqugvxU8/eU8= X-Google-Smtp-Source: APXvYqz3EliM0EqGJqKYJdmzIMfeoN9oQZxP/AxNDXUflMMPjphC2W81zQaU8sKTbB/pDCWvEgyz1A== X-Received: by 2002:a1c:f210:: with SMTP id s16mr3656620wmc.57.1579710460923; Wed, 22 Jan 2020 08:27:40 -0800 (PST) Received: from ?IPv6:2a02:c7f:ac73:9500:85af:2aa9:5413:b74e? ([2a02:c7f:ac73:9500:85af:2aa9:5413:b74e]) by smtp.gmail.com with ESMTPSA id p18sm4760147wmb.8.2020.01.22.08.27.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jan 2020 08:27:39 -0800 (PST) From: Lars Kurth X-Google-Original-From: Lars Kurth Message-Id: <052081D4-2F9F-401A-A6F6-8A9CDC1069AC@xenproject.org> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 22 Jan 2020 16:27:39 +0000 In-Reply-To: To: Andrew Cooper References: X-Mailer: Apple Mail (2.3445.104.11) Subject: Re: [Xen-devel] [RFC XEN PATCH 00/23] xen: beginning support for RISC-V X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Bobby Eshleman , Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Ian Jackson , Bobby Eshleman , Dan Robertson , Alistair Francis , xen-devel Content-Type: multipart/mixed; boundary="===============6122974368978164642==" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --===============6122974368978164642== Content-Type: multipart/alternative; boundary="Apple-Mail=_D5101D87-5F59-4DD5-9899-23BD99C89402" --Apple-Mail=_D5101D87-5F59-4DD5-9899-23BD99C89402 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 22 Jan 2020, at 14:57, Andrew Cooper = wrote: >=20 > On 22/01/2020 01:58, Bobby Eshleman wrote: >> Hey everybody, >>=20 >> 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.=20 >>=20 >> 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). >>=20 >> 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. >>=20 >> 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. >>=20 >> This patchset has _some_ code for future support for 32-bit, but >> currently my focus is on 64-bit. >>=20 >> 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. >>=20 >> My big questions are: >> Does the Xen project have interest in RISC-V? >=20 > There is very large downstream interest in RISC-V. So a definite yes. >=20 >> What can be done to make the RISC-V port as upstreamable as >> possible? >> Any major pitfalls? >>=20 >> It would be great to hear all of your feedback. >=20 > 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. >=20 > This series clearly demonstrates a change in the status quo, and I = think > a lot of people will be happy. >=20 > 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? >=20 > 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. >=20 > 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. >=20 > I hope this helps. I totally agree with what Andy says.=20 You should also leverage the developer summit: see = 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. Lars --Apple-Mail=_D5101D87-5F59-4DD5-9899-23BD99C89402 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 22 Jan 2020, at 14:57, Andrew Cooper <andrew.cooper3@citrix.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
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?

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/<= /div>
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.

Lars




= --Apple-Mail=_D5101D87-5F59-4DD5-9899-23BD99C89402-- --===============6122974368978164642== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbA== --===============6122974368978164642==--