kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anup Patel <anup@brainfault.org>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Anup Patel <Anup.Patel@wdc.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexander Graf <graf@amazon.com>,
	Atish Patra <Atish.Patra@wdc.com>,
	Alistair Francis <Alistair.Francis@wdc.com>,
	Damien Le Moal <Damien.LeMoal@wdc.com>,
	KVM General <kvm@vger.kernel.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	"linux-kernel@vger.kernel.org List"
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 <palmer@dabbelt.com> wrote:
> On Wed, 31 Mar 2021 02:21:58 PDT (-0700), pbonzini@redhat.com 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 ?


> 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

  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 [PATCH v16 00/17] KVM RISC-V Support 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:

* 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 \
    --to=anup@brainfault.org \
    --cc=Alistair.Francis@wdc.com \
    --cc=Anup.Patel@wdc.com \
    --cc=Atish.Patra@wdc.com \
    --cc=Damien.LeMoal@wdc.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=graf@amazon.com \
    --cc=kvm-riscv@lists.infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=pbonzini@redhat.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).