Message-ID: <alpine.DEB.2.22.394.2501161304480.2684657@ubuntu-linux-20-04-desktop>
Date: Thu, 16 Jan 2025 13:07:56 -0800 (PST)
From: Stefano Stabellini <sstabellini@...nel.org>
To: Milan Đokić <milandjokic1995@...il.com>
cc: Stefano Stabellini <sstabellini@...nel.org>, 
    Oleksii Kurochko <oleksii.kurochko@...il.com>, 
    linux-riscv@...ts.infradead.org, paul.walmsley@...ive.com, 
    palmer@...belt.com, aou@...s.berkeley.edu, jgross@...e.com, 
    oleksandr_tyshchenko@...m.com, Slavisa.Petrovic@...rk.com, 
    Milan.Djokic@...rk.com, rafael.j.wysocki@...el.com, 
    sunilvl@...tanamicro.com, takakura@...inux.co.jp, 
    linux-kernel@...r.kernel.org, xen-devel@...ts.xenproject.org, 
    iommu@...ts.linux.dev
Subject: Re: [PATCH] riscv: Add initial Xen guest support for RISC-Vgh

On Thu, 16 Jan 2025, Milan Đokić wrote:
> On Wed, Jan 15, 2025 at 10:14 PM Stefano Stabellini
> <sstabellini@...nel.org> wrote:
> >
> > On Wed, 15 Jan 2025, Milan Đokić wrote:
> > > Hello Stefano, Oleksii
> > >
> > > On Wed, Jan 15, 2025 at 5:30 PM Oleksii Kurochko
> > > <oleksii.kurochko@...il.com> wrote:
> > > >
> > > > Hi Stefano,
> > > >
> > > > On 1/15/25 1:01 AM, Stefano Stabellini wrote:
> > > >
> > > > +Oleksii
> > > >
> > > > On Tue, 14 Jan 2025, Milan Djokic wrote:
> > > >
> > > > From: Slavisa Petrovic <Slavisa.Petrovic@...rk.com>
> > > >
> > > > This patch introduces initial support for running RISC-V as a Xen guest.
> > > > It provides the necessary infrastructure and stubs for Xen-specific
> > > > operations. Key changes include:
> > > >
> > > > - Modifications to the RISC-V kernel to integrate Xen-specific hypercalls
> > > >   and interfaces, with function implementations stubbed for future work.
> > > > - Introduction of Xen-specific headers for RISC-V, including event
> > > >   handling, hypervisor interaction, and page management. Functions are
> > > >   defined but not yet implemented.
> > > > - Stub implementations for memory management, grant tables, and context
> > > >   switching in the Xen environment, allowing further development and
> > > >   integration.
> > > >
> > > > Signed-off-by: Milan Djokic <Milan.Djokic@...rk.com>
> > > > Signed-off-by: Slavisa Petrovic <Slavisa.Petrovic@...rk.com>
> > > >
> > > > Hi Milan, Slavisa,
> > > >
> > > > Thank you very much for your contribution! Which Xen tree are you using
> > > > for development?
> > > >
> > > > They are using [1] and have separate branches on top of latest. So we are in
> > > > sync. Also, if you are interested we have created a task/epics for this feature in
> > > > [1] so you could also check there some details:
> > > > 1. https://gitlab.com/groups/xen-project/people/olkur/-/epics/5
> > > > 2. https://gitlab.com/xen-project/people/olkur/xen/-/issues/12
> > > >
> > > >  I am asking because RISC-V support in Xen is still in
> > > > the process of being upstreamed, and [1] is the tree that consolidates
> > > > all patches currently on the to-be-upstreamed list.
> > > >
> > > > While the specific Xen tree you are using is not particularly important
> > > > at this stage, and using [1] is not a requirement, I am asking because
> > > > it is essential to align on the hypervisor ABI, especially regarding any
> > > > details that have not yet been upstreamed. Specifically, is there
> > > > anything in this patch series that relies on features not yet upstream
> > > > in Xen?
> > > >
> > > > There are few features but some things which are Rt-Tk's branch in [1] could go
> > > > without waiting for these features to be upstreamed.
> > > >
> > > > Thanks.
> > > >
> > > > ~ Oleksii
> > > >
> > > > [1] https://gitlab.com/xen-project/people/olkur/xen/-/tree/latest?ref_type=heads
> > >
> > > As Oleksii already explained, we are working in sync with his latest
> > > branch where most of the risc port is done.
> >
> > Perfect, I was hoping you'd say that! :-)
> > It is great to have you on board.
> >
> >
> > > I would just add that this patch introduces kernel risc-v hypercall
> > > support on which only our branch on xen tree depends on. Therefore, it
> > > won't disrupt any functionality with current upstream Xen, it will
> > > just introduce kernel functionality which is not used from Xen side
> > > until our branch is merged upstream.
> >
> > Ideally, we should upstream the Xen side of an interface first to Xen,
> > then add support for the interface to Linux. Let me make a concrete
> > example. Let's say that you upstream hypercall support to Linux first,
> > using SBI_ECALL defined as 0xE. Then, during the upstreaming process,
> > the Xen community decides to change SBI_ECALL to 0XEA1 to make it the
> > same as ARM. You'd have to change the Linux code again to fix it. To
> > avoid this, it is best to wait upstreaming the Linux side, until the Xen
> > side is Acked.
> >
> Sure, I got your point. This is actually one of the things we were not
> sure about (whether we should upstream Linux or Xen side first).
> Anyways it's good that we got review comments. We'll fix this patch
> according to suggestions and send it back when Xen side is upstream.

Thank you! In general, "first upstream to Xen, then to Linux" is a good
guideline, but we can be flexible. For instance, in the case of
hypercalls that seem pretty obvious how we are going to implement them,
it might be sufficient to send a simple patch to Xen to add a document
under xen.git/docs/ to document how the hypercall ABI will look like on
RISC-V, without the implementation. With that document committed to
xen.git, we can go forward with upstreaming the Linux side, even if the
upstream Xen implementation is still lacking.

Powered by blists - more mailing lists