> On 22 Jan 2020, at 14:57, Andrew Cooper <andrew.coop...@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/ <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
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
