[<prev] [next>] [day] [month] [year] [list]
Message-ID: <ce3bb9f5c72f0feb1cf9a0d67edaedf6@mailhost.ics.forth.gr>
Date: Tue, 28 Sep 2021 03:23:37 +0300
From: Nick Kossifidis <mick@....forth.gr>
To: Greg Favor <gfavor@...tanamicro.com>
Cc: Atish Patra <atishp@...shpatra.org>,
Philipp Tomsich <philipp.tomsich@...ll.eu>,
Guo Ren <guoren@...nel.org>,
Palmer Dabbelt <palmer@...belt.com>,
Anup Patel <anup.patel@....com>,
Atish Patra <atish.patra@....com>,
Palmer Dabbelt <palmerdabbelt@...gle.com>,
Christoph Müllner <christoph.muellner@...ll.eu>,
Christoph Hellwig <hch@....de>,
liush <liush@...winnertech.com>, wefu@...hat.com,
Wei Wu (吴伟) <lazyparser@...il.com>,
Drew Fustini <drew@...gleboard.org>,
linux-riscv <linux-riscv@...ts.infradead.org>,
"linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
taiten.peng@...onical.com, aniket.ponkshe@...onical.com,
Heinrich Schuchardt <heinrich.schuchardt@...onical.com>,
gordan.markus@...onical.com, Guo Ren <guoren@...ux.alibaba.com>,
Arnd Bergmann <arnd@...db.de>, Chen-Yu Tsai <wens@...e.org>,
Maxime Ripard <maxime@...no.tech>,
Daniel Lustig <dlustig@...dia.com>,
Andrea Mondelli <andrea.mondelli@...wei.com>,
Jonathan Behrens <behrensj@....edu>,
Xinhaoqu <xinhaoqu@...wei.com>,
Bill Huffman <huffman@...ence.com>,
Nick Kossifidis <mick@....forth.gr>,
Allen Baum <allen.baum@...erantotech.com>,
Josh Scheid <jscheid@...tanamicro.com>,
Richard Trauben <rtrauben@...il.com>
Subject: Re: [PATCH V2 1/2] riscv: Add RISC-V svpbmt extension
Hello Greg,
Στις 2021-09-27 23:53, Greg Favor έγραψε:
> With the big caveat that I haven't been in the middle of this
> discussion, it seems like Allwinner D1's changes represent a custom
> (and nonconforming) extension. Isn't this just a matter of the patch
> needing to be treated as for a RISC-V custom extension per the recently
> clarified policy for handling upstreaming/etc. of custom extensions?
> (Philipp can speak to this clarified policy.) Or what am I missing?
>
The Priv. Spec. defines sv39/48 without allowing custom use of reserved
pte bits by implementations, Allwinner D1 claims to be sv39 but it does
use reserved PTE bits. When vendors want to do custom stuff on PTEs, the
standard says they may use values 14-15 on satp.mode for that and define
their own MMU basically. Messing up with the implementation of sv39 is
not an extension, is violation of sv39. Even worse this implementation
can't work if we ignore the customization since without setting the
required bits on PTEs dma (and I believe SMP as well) doesn't work.
Regards,
Nick
Powered by blists - more mailing lists