Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: QHjzdW5EFe5chYEQdl6q8PP5VzM8G+AQPhy6Yi72v6M7ozQ8c+CLW3kqOoHej5v/j2+ZJqLN4+
 9VraZLV4ElnXzzz8EsgXmDOJMsW/BRhwv3/wWm09jJekON5Qdf0zAmMBDK9uQgJLcaayjhvcxF
 NW2u6sFqs5A8ZoyV+dxvYHd/+3jyA16/lnHo/AuFDvvdvqNrP0a9WANa+kPP/pdBFpLEB8l83E
 AHMHHZ8Y2/CviMeMYSYW+c+uSZa/9d3dt81EoKWVH1gJd/rzIz4sm0Vh3imKiCakqfr2NVBQ+a
 EZg=
From:   Damien Le Moal <Damien.LeMoal@wdc.com>
To:     Greg KH <gregkh@linuxfoundation.org>
CC:     Palmer Dabbelt <palmerdabbelt@google.com>,
        "guoren@kernel.org" <guoren@kernel.org>,
        Anup Patel <Anup.Patel@wdc.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        "aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "graf@amazon.com" <graf@amazon.com>,
        Atish Patra <Atish.Patra@wdc.com>,
        Alistair Francis <Alistair.Francis@wdc.com>,
        "anup@brainfault.org" <anup@brainfault.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "kvm-riscv@lists.infradead.org" <kvm-riscv@lists.infradead.org>,
        "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-staging@lists.linux.dev" <linux-staging@lists.linux.dev>
Subject: Re: [PATCH v18 00/18] KVM RISC-V Support
Thread-Topic: [PATCH v18 00/18] KVM RISC-V Support
Thread-Index: AQHXTGAgKECmO/ER7EehkQtXersO1g==
Date:   Tue, 25 May 2021 08:01:01 +0000
Message-ID: <DM6PR04MB7081843419AFCECABA75AD74E7259@DM6PR04MB7081.namprd04.prod.outlook.com>
References: <mhng-b093a5aa-ff9d-437f-a10b-47558f182639@palmerdabbelt-glaptop>
 <DM6PR04MB708173B754E145BC843C4123E7269@DM6PR04MB7081.namprd04.prod.outlook.com>
 <YKypJ5SJg2sDtn7/@kroah.com>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9355121c-ce25-4381-ae9a-08d91f533ce8
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2021 08:01:01.3706
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: khNl1E77Z884NdL90degL8CQ/jcQq8lLBf/ptl/jnl1oONyWN3s8nPMdQ394YqUqMIAC7Iof1//bKeEbA0MA9Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR04MB5996
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2021/05/25 16:37, Greg KH wrote:=0A=
> On Mon, May 24, 2021 at 11:08:30PM +0000, Damien Le Moal wrote:=0A=
>> On 2021/05/25 7:57, Palmer Dabbelt wrote:=0A=
>>> On Mon, 24 May 2021 00:09:45 PDT (-0700), guoren@kernel.org wrote:=0A=
>>>> Thx Anup,=0A=
>>>>=0A=
>>>> Tested-by: Guo Ren <guoren@kernel.org> (Just on qemu-rv64)=0A=
>>>>=0A=
>>>> I'm following your KVM patchset and it's a great job for riscv=0A=
>>>> H-extension. I think hardware companies hope Linux KVM ready first=0A=
>>>> before the real chip. That means we can ensure the hardware could run=
=0A=
>>>> mainline linux.=0A=
>>>=0A=
>>> I understand that it would be wonderful for hardware vendors to have a =
=0A=
>>> guarantee that their hardware will be supported by the software =0A=
>>> ecosystem, but that's not what we're talking about here.  Specifically,=
 =0A=
>>> the proposal for this code is to track the latest draft extension which=
 =0A=
>>> would specifically leave vendors who implement the current draft out in=
 =0A=
>>> the cold was something to change.  In practice that is the only way to =
=0A=
>>> move forward with any draft extension that doesn't have hardware =0A=
>>> available, as the software RISC-V implementations rapidly deprecate =0A=
>>> draft extensions and without a way to test our code it is destined to =
=0A=
>>> bit rot.=0A=
>>=0A=
>> To facilitate the process of implementing, and updating, against draft=
=0A=
>> specifications, I proposed to have arch/riscv/staging added. This would =
be the=0A=
>> place to put code based on drafts. Some simple rules can be put in place=
:=0A=
>> 1) The code and eventual ABI may change any time, no guarantees of backw=
ard=0A=
>> compatibility=0A=
>> 2) Once the specifications are frozen, the code is moved out of staging=
=0A=
>> somewhere else.=0A=
>> 3) The code may be removed any time if the specification proposal is dro=
pped, or=0A=
>> any other valid reason (can't think of any other right now)=0A=
>> 4) ...=0A=
>>=0A=
>> This way, the implementation process would be greatly facilitated and=0A=
>> interactions between different extensions can be explored much more easi=
ly.=0A=
>>=0A=
>> Thoughts ?=0A=
> =0A=
> It will not work, unless you are mean and ruthless and people will get=0A=
> mad at you.  I do not recommend it at all.=0A=
> =0A=
> Once code shows up in the kernel tree, and people rely on it, you now=0A=
> _have_ to support it.  Users don't know the difference between "staging=
=0A=
> or not staging" at all.  We have reported problems of staging media=0A=
> drivers breaking userspace apps and people having problems with that,=0A=
> despite the media developers trying to tell the world, "DO NOT RELY ON=0A=
> THESE!".=0A=
> =0A=
> And if this can't be done with tiny simple single drivers, you are going=
=0A=
> to have a world-of-hurt if you put arch/platform support into=0A=
> arch/riscv/.  Once it's there, you will never be able to delete it,=0A=
> trust me.=0A=
=0A=
All very good points. Thank you for sharing.=0A=
=0A=
> If you REALLY wanted to do this, you could create drivers/staging/riscv/=
=0A=
> and try to make the following rules:=0A=
> =0A=
> 	- stand-alone code only, can not depend on ANYTHING outside of=0A=
> 	  the directory that is not also used by other in-kernel code=0A=
> 	- does not expose any userspace apis=0A=
> 	- interacts only with existing in-kernel code.=0A=
> 	- can be deleted at any time, UNLESS someone is using it for=0A=
> 	  functionality on a system=0A=
> =0A=
> But what use would that be?  What could you put into there that anyone=0A=
> would be able to actually use?=0A=
=0A=
Yes, you already mentioned this and we were not thinking about this solutio=
n.=0A=
drivers/staging really is for device drivers and does not apply to arch cod=
e.=0A=
=0A=
> Remember the rule we made to our user community over 15 years ago:=0A=
> =0A=
> 	We will not break userspace functionality*=0A=
> =0A=
> With the caveat of "* - in a way that you notice".=0A=
> =0A=
> That means we can remove and change things that no one relies on=0A=
> anymore, as long as if someone pops up that does rely on it, we put it=0A=
> back.=0A=
> =0A=
> We do this because we never want anyone to be afraid to drop in a new=0A=
> kernel, because they know we did not break their existing hardware and=0A=
> userspace workloads.  And if we did, we will work quickly to fix it.=0A=
=0A=
Yes, I am well aware of this rule.=0A=
=0A=
> So back to the original issue here, what is the problem that you are=0A=
> trying to solve?  Why do you want to have in-kernel code for hardware=0A=
> that no one else can have access to, and that isn't part of a "finalized=
=0A=
> spec" that ends up touching other subsystems and is not self-contained?=
=0A=
=0A=
For the case at hand, the only thing that would be outside of the staging a=
rea=0A=
would be the ABI definition, but that one depends only on the ratified risc=
v ISA=0A=
specs. So having it outside of staging would be OK. The idea of the arch st=
aging=0A=
area is 2 fold:=0A=
1) facilitate the development work overall, both for Paolo and Anup on the =
KVM=0A=
part, but also others to check that their changes do not break KVM support.=
=0A=
2) Provide feedback to the specs groups that their concerns are moot. E.g. =
one=0A=
reason the hypervisor specs are being delayed is concerns with interrupt=0A=
handling. With a working implementation based on current ratified specs for=
=0A=
other components (e.g. interrupt controller), the hope is that the specs gr=
oup=0A=
can speed up freezing of the specs.=0A=
=0A=
But your points about how users will likely end up using this potentially=
=0A=
creates a lot more problems than we are solving...=0A=
=0A=
> Why not take the energy here and go get that spec ratified so we aren't=
=0A=
> having this argument anymore?  What needs to be done to make that happen=
=0A=
> and why hasn't anyone done that?  There's nothing keeping kernel=0A=
> developers from working on spec groups, right?=0A=
=0A=
We are participating and giving arguments for freezing the specs. This is=
=0A=
however not working as we would like. But that is a problem to be addressed=
 with=0A=
RISCV International and the processes governing the operation of specificat=
ion=0A=
groups. The linux mailing lists are not the right place to discuss this, so=
 I=0A=
will not go into more details.=0A=
=0A=
Thank you for the feedback.=0A=
=0A=
Best regards.=0A=
=0A=
-- =0A=
Damien Le Moal=0A=
Western Digital Research=0A=