linux-kernel - Re: [PATCH] riscv: Add initial Xen guest support for RISC-Vgh

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.22.394.2501151313590.2684657@ubuntu-linux-20-04-desktop>
Date: Wed, 15 Jan 2025 13:14:04 -0800 (PST)
From: Stefano Stabellini <sstabellini@...nel.org>
To: Milan Đokić <milandjokic1995@...il.com>
cc: Oleksii Kurochko <oleksii.kurochko@...il.com>, 
    Stefano Stabellini <sstabellini@...nel.org>, 
    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 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.

This was just an example, and Andrew is right that the SBI
Implementation ID for Xen is reserved to 0x7, see the SBI specification.