From: Anup Patel <firstname.lastname@example.org> To: Palmer Dabbelt <email@example.com> Cc: Paolo Bonzini <firstname.lastname@example.org>, Anup Patel <Anup.Patel@wdc.com>, Paul Walmsley <email@example.com>, Albert Ou <firstname.lastname@example.org>, Alexander Graf <email@example.com>, Atish Patra <Atish.Patra@wdc.com>, Alistair Francis <Alistair.Francis@wdc.com>, Damien Le Moal <Damien.LeMoal@wdc.com>, KVM General <firstname.lastname@example.org>, email@example.com, linux-riscv <firstname.lastname@example.org>, "email@example.com List" <firstname.lastname@example.org> Subject: Re: [PATCH v16 00/17] KVM RISC-V Support Date: Wed, 21 Apr 2021 09:38:01 +0530 [thread overview] Message-ID: <CAAhSdy1EYhgA52m48DcyevM5j5EsuXPbVq5Z0KHB+SaXorNTeg@mail.gmail.com> (raw) In-Reply-To: <mhng-d64da1be-bacd-4885-aaf2-fea3c763418c@palmerdabbelt-glaptop> Hi Palmer, On Sat, Apr 10, 2021 at 12:28 AM Palmer Dabbelt <email@example.com> wrote: > > On Wed, 31 Mar 2021 02:21:58 PDT (-0700), firstname.lastname@example.org wrote: > > On 30/03/21 07:48, Anup Patel wrote: > >> > >> It seems Andrew does not want to freeze H-extension until we have virtualization > >> aware interrupt controller (such as RISC-V AIA specification) and IOMMU. Lot > >> of us feel that these things can be done independently because RISC-V > >> H-extension already has provisions for external interrupt controller with > >> virtualization support. > > Sorry to hear that. It's really gotten to a point where I'm just > embarrassed with how the RISC-V foundation is being run -- not sure if > these other ones bled into Linux land, but this is the third ISA > extension that's blown up over the last few weeks. We had a lot of > discussion about this on the binutils/GCC side of things and I've > managed to convince myself that coupling the software stack to the > specification process isn't viable -- we made that decision under the > assumption that specifications would actually progress through the > process, but in practice that's just not happening. > > My goal with the RISC-V stuff has always been getting us to a place > where we have real shipping products running a software stack that is as > close as possible to the upstream codebases. I see that as the only way > to get the software stack to a point where it can be sustainably > maintained. The "only frozen extensions" policy was meant to help this > by steering vendors towards a common base we could support, but in > practice it's just not working out. The specification process is just > so unreliable that in practice everything that gets built ends up > relying on some non-standard behavior: whether it's a draft extension, > some vendor-specific extension, or just some implementation quirks. > There's always going to be some degree of that going on, but over the > last year or so we've just stopped progressing. > > My worry with accepting the draft extensions is that we have no > guarantee of compatibility between various drafts, which makes > supporting multiple versions much more difficult. I've always really > only been worried about supporting what gets implemented in a chip I can > actually run code on, as I can at least guarantee that doesn't change. > In practice that really has nothing to do with the specification freeze: > even ratified specifications change in ways that break compatibility so > we need to support multiple versions anyway. That's why we've got > things like the K210 support (which doesn't quite follow the ratified > specs) and are going to take the errata stuff. I hadn't been all that > worried about the H support because there was a plan to get is to > hardware, but with the change I'm not really sure how that's going to > happen. > > > Yes, frankly that's pretty ridiculous as it's perfectly possible to > > emulate the interrupt controller in software (and an IOMMU is not needed > > at all if you are okay with emulated or paravirtualized devices---which > > is almost always the case except for partitioning hypervisors). > > There's certainly some risk to freezing the H extension before we have > all flavors of systems up and running. I spent a lot of time arguing > that case years ago before we started telling people that the H > extension just needed implementation, but that's not the decision we > made. I don't really do RISC-V foundation stuff any more so I don't > know why this changed, but it's just too late. It would be wonderful to > have an implementation of everything we need to build out one of these > complex systems, but I just just don't see how the current plan gets > there: that's a huge amount of work and I don't see why anyone would > commit to that when they can't count on it being supported when it's > released. > > There are clearly some systems that can be built with this as it stands. > They're not going to satisfy every use case, but at least we'll get > people to start seriously using the spec. That's the only way I can see > to move forward with this. It's pretty clear that sitting around and > waiting doesn't work, we've tried that. > > > Palmer, are you okay with merging RISC-V KVM? Or should we place it in > > drivers/staging/riscv/kvm? > > I'm certainly ready to drop my objections to merging the code based on > it targeting a draft extension, but at a bare minimum I want to get a > new policy in place that everyone can agree to for merging code. I've > tried to draft up a new policy a handful of times this week, but I'm not > really quite sure how to go about this: ultimately trying to build > stable interfaces around an unstable ISA is just a losing battle. I've > got a bunch of stuff going on right now, but I'll try to find some time > to actually sit down and finish one. Can you send the patch for the updated policy which we can review ?? Will it be possible to get KVM RISC-V merged for Linux-5.13 ? Regards, Anup > > I know it might seem odd to complain about how slowly things are going > and then throw up another roadblock, but I really do think this is a > very important thing to get right. I'm just not sure how we're going to > get anywhere with RISC-V without someone providing stability, so I want > to make sure that whatever we do here can be done reliably. If we don't > I'm worried the vendors are just going to go off and do their own > software stacks, which will make getting everyone back on the same page > very difficult. > > > Either way, the best way to do it would be like this: > > > > 1) you apply patch 1 in a topic branch > > > > 2) you merge the topic branch in the risc-v tree > > > > 3) Anup merges the topic branch too and sends me a pull request. > > > > Paolo
next prev parent reply other threads:[~2021-04-21 4:08 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-15 12:18 Anup Patel 2021-01-15 12:18 ` [PATCH v16 01/17] RISC-V: Add hypervisor extension related CSR defines Anup Patel 2021-01-15 12:18 ` [PATCH v16 02/17] RISC-V: Add initial skeletal KVM support Anup Patel 2021-01-15 12:18 ` [PATCH v16 03/17] RISC-V: KVM: Implement VCPU create, init and destroy functions Anup Patel 2021-01-15 12:18 ` [PATCH v16 04/17] RISC-V: KVM: Implement VCPU interrupts and requests handling Anup Patel 2021-01-15 12:18 ` [PATCH v16 05/17] RISC-V: KVM: Implement KVM_GET_ONE_REG/KVM_SET_ONE_REG ioctls Anup Patel 2021-01-15 12:18 ` [PATCH v16 06/17] RISC-V: KVM: Implement VCPU world-switch Anup Patel 2021-01-15 12:18 ` [PATCH v16 07/17] RISC-V: KVM: Handle MMIO exits for VCPU Anup Patel 2021-01-15 12:18 ` [PATCH v16 08/17] RISC-V: KVM: Handle WFI " Anup Patel 2021-01-15 12:18 ` [PATCH v16 09/17] RISC-V: KVM: Implement VMID allocator Anup Patel 2021-01-15 12:18 ` [PATCH v16 10/17] RISC-V: KVM: Implement stage2 page table programming Anup Patel 2021-01-15 12:18 ` [PATCH v16 11/17] RISC-V: KVM: Implement MMU notifiers Anup Patel 2021-01-15 12:18 ` [PATCH v16 12/17] RISC-V: KVM: Add timer functionality Anup Patel 2021-01-15 12:18 ` [PATCH v16 13/17] RISC-V: KVM: FP lazy save/restore Anup Patel 2021-01-15 12:18 ` [PATCH v16 14/17] RISC-V: KVM: Implement ONE REG interface for FP registers Anup Patel 2021-01-15 12:18 ` [PATCH v16 15/17] RISC-V: KVM: Add SBI v0.1 support Anup Patel 2021-01-15 12:18 ` [PATCH v16 16/17] RISC-V: KVM: Document RISC-V specific parts of KVM API Anup Patel 2021-01-15 12:18 ` [PATCH v16 17/17] RISC-V: KVM: Add MAINTAINERS entry Anup Patel 2021-01-23 3:40 ` [PATCH v16 00/17] KVM RISC-V Support Palmer Dabbelt 2021-03-30 5:48 ` Anup Patel 2021-03-31 9:21 ` Paolo Bonzini 2021-04-01 13:24 ` Anup Patel 2021-04-09 18:58 ` Palmer Dabbelt 2021-04-21 4:08 ` Anup Patel [this message] 2021-04-27 5:43 ` Paul Walmsley 2021-04-27 6:01 ` Anup Patel 2021-04-27 7:04 ` Paolo Bonzini 2021-04-28 7:07 ` Anup Patel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAAhSdy1EYhgA52m48DcyevM5j5EsuXPbVq5Z0KHB+SaXorNTeg@mail.gmail.com \ --email@example.com \ --cc=Alistair.Francis@wdc.com \ --cc=Anup.Patel@wdc.com \ --cc=Atish.Patra@wdc.com \ --cc=Damien.LeMoal@wdc.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v16 00/17] KVM RISC-V Support' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).