Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1402569pxj; Fri, 21 May 2021 13:23:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyWd3xiw1RH0Qyn7fb+FKsKCIcae/iBnJWypzl5boQ4AMUMM7jgFOPGhuWQOnqnJjSLfaHH X-Received: by 2002:a05:6638:3445:: with SMTP id q5mr6843902jav.120.1621628595133; Fri, 21 May 2021 13:23:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621628595; cv=none; d=google.com; s=arc-20160816; b=ncsheUNSnyBuklfcE4uAZRABpJ0QfAq8k7/fwwWlqTLgxwqv8g4nsD4tJseNNj+9iN C8PKL3Ls5zgKPiV7gyJsjIvSuDgfRDV4A1Nzx1Ybkz14xHEh/z0mvM9SITiWKHyXUq4r b0GjDNzNvnoouBebI9IgdtsHydPiZcjYCHLxvNcas8khow3W53p6vLb3ByHaIpGzgLnn G25GeBPGSiZfmYb9l2CIhA4CCTGd6vEibIzlwpHnG8ezjshuuZfblE+VGTOTgsfA7ANv ehyh7MiIXVqRu+JT5fZ6WA4p8TnYD0yFg8p2DxU8kWyrIVIGG4Grthopk+AUH+mN8olZ q7Dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:to:from:cc:in-reply-to:subject:date:dkim-signature; bh=p2CM4MP1hrRU7+fp/2zo1m41ON9YEIddlJq9crMKEbQ=; b=FNeiZVttPF1V614HHKlw3C7u5mpS+OCcljAmYsT47ZFExSmfTsoRxkGw7TokCv5YtZ ZK9euCYnqLvhLCh9rPWeJqMp5lYm1r0dpNKd8++V/frWy5HcgBJO1cdtSnRvj2uPaZx+ gWpi6dwfiAHjEZcVlOvJbkDh1qsg1ZdFT9NIixjbK504uQXtoS+rP7BVPymCWiUZ8OPR KRzTERAhQc5/OFNVl/dYiCVIHAq21/n0ZzdfjxU61siN9czE3WFD5+uTOfzK3k6NZbqC YeIB2weTJMhuvyb46n/LX2dku/gW9QGeWYR3Hbhp7q4e6yHoHojbpxHpNPfwH8xJxwfA 1U4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=WvhGtpTt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d1si7608308ilg.93.2021.05.21.13.23.02; Fri, 21 May 2021 13:23:15 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=WvhGtpTt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238043AbhEURPO (ORCPT + 99 others); Fri, 21 May 2021 13:15:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50628 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238038AbhEURPO (ORCPT ); Fri, 21 May 2021 13:15:14 -0400 Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8D216C0613CE for ; Fri, 21 May 2021 10:13:49 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id v14so12007520pgi.6 for ; Fri, 21 May 2021 10:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=p2CM4MP1hrRU7+fp/2zo1m41ON9YEIddlJq9crMKEbQ=; b=WvhGtpTtoEx7HB0OPZ9XjTR7ilqHsmcVhV+jR+vZfFiYg2FnMLwOVPsXw2ZRiUvu2E m77gyRAWP89uByNmIR+cp2s3sOXUCFlP99iU0AXmwEH5nhyFkLQOwZD6VSQrDz6p154/ M9tl5at5CemBY3QVAgugGPnO9jRnkotNdtIJO4tSIIZkBtRCV8/W5W/BOlgxTpfEMY9L cgSSHs3P94wNf0C7r3iM9TmE35DtyuUo0RUxd2LIPiZW6WovaLsD3kBhjnURNVN/IhZc psscXncnndby1OpwTWGEsWTQpD2jn7h4m2nMr0L1nMeutBoiPkp4c8GzMv5ueoTfDGQk gfnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=p2CM4MP1hrRU7+fp/2zo1m41ON9YEIddlJq9crMKEbQ=; b=MhgVi/AgahVvJBezQcQWkxCfIxAi1hNYU0JZvAAmRFWL8e4fdVvbrfnIgEyB1TbJXJ VhylGpIKxhY0whpDh/+Zaro3pHkTRngkBF8Aw1KvYm62tm1ZH3n1OzvEcbpNVNAXoMXs kfsRnDps0/GUh7ZZSoN1ZtVwvaZ7JtftSe9XDSCCKqJ0YsGp7wmTk7iKx4L+1ZyL1f7G EXg/U288CgdkOKRcbQZVyM8ABz0d09+Wz12vm5ypQRyXB2xAQ+7EH0Afubg7uaIc5fyV iMZSpWiBcSmOe7aNoa1a6nK6CJDpcm50xAScf8pOjwReackh3GAGzQ/uqEAuaE6Fmd0m lExA== X-Gm-Message-State: AOAM531uKY8aucVpzAa5BaFI6+gx0pxkNgz2H4RKwxIxmj3wYsso5txE s030x7Y6bY5EKSifJsCVwB8xzQ== X-Received: by 2002:a65:6256:: with SMTP id q22mr10962068pgv.391.1621617228692; Fri, 21 May 2021 10:13:48 -0700 (PDT) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id ci2sm4624395pjb.56.2021.05.21.10.13.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 May 2021 10:13:47 -0700 (PDT) Date: Fri, 21 May 2021 10:13:47 -0700 (PDT) X-Google-Original-Date: Fri, 21 May 2021 10:13:45 PDT (-0700) Subject: Re: [PATCH v18 00/18] KVM RISC-V Support In-Reply-To: CC: pbonzini@redhat.com, anup@brainfault.org, Anup Patel , Paul Walmsley , aou@eecs.berkeley.edu, corbet@lwn.net, graf@amazon.com, Atish Patra , Alistair Francis , Damien Le Moal , kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev From: Palmer Dabbelt To: Greg KH Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 19 May 2021 06:58:05 PDT (-0700), Greg KH wrote: > On Wed, May 19, 2021 at 03:29:24PM +0200, Paolo Bonzini wrote: >> On 19/05/21 14:23, Greg Kroah-Hartman wrote: >> > > - the code could be removed if there's no progress on either changing the >> > > RISC-V acceptance policy or ratifying the spec >> > >> > I really do not understand the issue here, why can this just not be >> > merged normally? >> >> Because the RISC-V people only want to merge code for "frozen" or "ratified" >> processor extensions, and the RISC-V foundation is dragging their feet in >> ratifying the hypervisor extension. >> >> It's totally a self-inflicted pain on part of the RISC-V maintainers; see >> Documentation/riscv/patch-acceptance.rst: >> >> We'll only accept patches for new modules or extensions if the >> specifications for those modules or extensions are listed as being >> "Frozen" or "Ratified" by the RISC-V Foundation. (Developers may, of >> course, maintain their own Linux kernel trees that contain code for >> any draft extensions that they wish.) >> >> (Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/riscv/patch-acceptance.rst) > > Lovely, and how is that going to work for code that lives outside of the > riscv "arch" layer? Like all drivers? > > And what exactly is "not ratified" that these patches take advantage of? > If there is hardware out there with these features, well, Linux needs to > run on it, so we need to support that. No external committee rules > should be relevant here. > > Now if this is for hardware that is not "real", then that's a different > story. In that case, who cares, no one can use it, so why not take it? > > So what exactly is this trying to "protect" Linux from? > >> > All staging drivers need a TODO list that shows what needs to be done in >> > order to get it out of staging. All I can tell so far is that the riscv >> > maintainers do not want to take this for "unknown reasons" so let's dump >> > it over here for now where we don't have to see it. >> > >> > And that's not good for developers or users, so perhaps the riscv rules >> > are not very good? >> >> I agree wholeheartedly. >> >> I have heard contrasting opinions on conflict of interest where the >> employers of the maintainers benefit from slowing down the integration of >> code in Linus's tree. I find these allegations believable, but even if that >> weren't the case, the policy is (to put it kindly) showing its limits. > > Slowing down code merges is horrible, again, if there's hardware out > there, and someone sends code to support it, and wants to maintain it, > then we should not be rejecting it. > > Otherwise we are not doing our job as an operating system kernel, our > role is to make hardware work. We don't get to just ignore code because > we don't like the hardware (oh if only we could!), if a user wants to > use it, our role is to handle that. > >> > > Of course there should have been a TODO file explaining the situation. But >> > > if you think this is not the right place, I totally understand; if my >> > > opinion had any weight in this, I would just place it in arch/riscv/kvm. >> > > >> > > The RISC-V acceptance policy as is just doesn't work, and the fact that >> > > people are trying to work around it is proving it. There are many ways to >> > > improve it: >> > >> > What is this magical acceptance policy that is preventing working code >> > from being merged? And why is it suddenly the rest of the kernel >> > developer's problems because of this? >> >> It is my problem because I am trying to help Anup merging some perfectly >> good KVM code; when a new KVM port comes up, I coordinate merging the first >> arch/*/kvm bits with the arch/ maintainers and from that point on that >> directory becomes "mine" (or my submaintainers'). > > Agreed, but the riscv maintainers should not be forcing this "problem" > onto all of us, like it seems is starting to happen :( > > Ok, so, Paul, Palmer, and Albert, what do we do here? Why can't we take > working code like this into the kernel if someone is willing to support > and maintain it over time? I don't view this code as being in a state where it can be maintained, at least to the standards we generally set within the kernel. The ISA extension in question is still subject to change, it says so right at the top of the H extension {\bf Warning! This draft specification may change before being accepted as standard by the RISC-V Foundation.} That means we really can't rely on any of this to be compatible with what is eventually ratified and (hopefully, because this is really important stuff) widely implemented in hardware. We've already had isuses with other specifications where drafts were propossed as being ready for implemnetation, software was ported, and the future drafts were later incompatible -- we had this years ago with the debug support, which was a huge headache to deal with, and we're running into it again with these v-0.7.1 chips coming out. I don't want to get stuck in a spot where we're forced to either deal with some old draft extension forever or end up breaking users. Ultimately the whole RISC-V thing is only going to work out if we can get to the point where vendors can agree on a shared ISA. I understand that there's been a lot of frustration WRT the timelines on the H extension, it's been frustrating for me as well. There are clearly issues with how the ISA development process is being run and while those are coming to a head in other areas (the V extension and non-coherent devices, for example) I really don't think that's the case here because as far as I know we don't actually have any real hardware that implements the H extension. All I really care about is getting to the point where we have real RISC-V systems running software that's as close to upstream as is reasonable. As it currently stands, I don't know of anything this is blocking: there's some RTL implementation floating around, but that's a very long way from being real hardware. Something of this complexity isn't suitable for a soft core, and RTL alone doesn't fix the fundamental problem of having a stable platform to run on (it needs a complex FPGA environment, and even then it's very limited in functionality). I'm not sure where exactly the line for real hardware is, but for something like this it would at least involve some chip that is widely availiable and needs the H extension to be useful. Such a system existing without a ratified extension would obviously be a major failing on the specification side, and while I think that's happening now for some systems (some of these V-0.7.1 chips, and the non-coherent systems) I just don't see that as the case for the H extension. We've got to get to the point where the ISA extensions can be ratified in a timely fashion, but circumventing that process by merging code early doesn't fix the problem. This really needs to be fixed at the RISC-V foundation, not papered over in software.  We have lots of real RISC-V hardware right now that's going to require a huge amount of work to support, trying to chase around a draft extension that may not even end up in hardware is just going to make headaches we don't have the time for.