[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAhSdy3tJ3RbnyOtKAT4zsjPUxMQkm+UtWa4sTTZxSAsYUBs5g@mail.gmail.com>
Date: Wed, 7 Aug 2019 09:42:29 +0530
From: Anup Patel <anup@...infault.org>
To: Paul Walmsley <paul.walmsley@...ive.com>
Cc: Atish Patra <atish.patra@....com>, Anup Patel <anup.patel@....com>,
"linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
Alan Kao <alankao@...estech.com>,
Albert Ou <aou@...s.berkeley.edu>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
devicetree@...r.kernel.org, Enrico Weigelt <info@...ux.net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Johan Hovold <johan@...nel.org>,
linux-riscv <linux-riscv@...ts.infradead.org>,
Mark Rutland <mark.rutland@....com>,
Palmer Dabbelt <palmer@...ive.com>,
Rob Herring <robh+dt@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v4 2/4] RISC-V: Add riscv_isa reprensenting ISA features
common across CPUs
On Wed, Aug 7, 2019 at 3:24 AM Paul Walmsley <paul.walmsley@...ive.com> wrote:
>
> Hi Anup, Atish,
>
> On Fri, 2 Aug 2019, Atish Patra wrote:
>
> > From: Anup Patel <anup.patel@....com>
> >
> > This patch adds riscv_isa integer to represent ISA features common
> > across all CPUs. The riscv_isa is not same as elf_hwcap because
> > elf_hwcap will only have ISA features relevant for user-space apps
> > whereas riscv_isa will have ISA features relevant to both kernel
> > and user-space apps.
> >
> > One of the use case is KVM hypervisor where riscv_isa will be used
> > to do following operations:
> >
> > 1. Check whether hypervisor extension is available
> > 2. Find ISA features that need to be virtualized (e.g. floating
> > point support, vector extension, etc.)
> >
> > Signed-off-by: Anup Patel <anup.patel@....com>
> > Signed-off-by: Atish Patra <atish.patra@....com>
>
> Do you have any opinions on how this patch might change for the Z-prefix
> extensions? This bitfield approach probably won't scale, and with the
> EXPORT_SYMBOL(), it might be worth trying to put together a approach that
> would work over the long term?
Our plan is to use bitmap instead of bitfield and all Zxyz extensions will be
assigned bit positions "27 + i" where "i" will be based on order in-which they
are defined in RISC-V spec. In general, "i" is just a unique relative index
(starting from 0).
To summarize, the existing bitfield approach can be naturally extended
using bitmap.
We will update this patch accordingly.
Regards,
Anup
Powered by blists - more mailing lists