From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Anup Patel <apatel@ventanamicro.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Atish Patra <atishp@atishpatra.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Jiri Slaby <jirislaby@kernel.org>,
Conor Dooley <conor@kernel.org>,
Andrew Jones <ajones@ventanamicro.com>,
kvm@vger.kernel.org, kvm-riscv@lists.infradead.org,
linux-riscv@lists.infradead.org, linux-serial@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/6] RISC-V: KVM: Forward SBI DBCN extension to user-space
Date: Wed, 11 Oct 2023 09:25:56 +0200 [thread overview]
Message-ID: <2023101105-oink-aerospace-989e@gregkh> (raw)
In-Reply-To: <CAK9=C2UEcQpHg8WZM3XxLa5yCEZ6wtWJj=8g5_m_0_RkiNMkTA@mail.gmail.com>
On Wed, Oct 11, 2023 at 12:02:30PM +0530, Anup Patel wrote:
> On Tue, Oct 10, 2023 at 10:45 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Oct 10, 2023 at 10:35:00PM +0530, Anup Patel wrote:
> > > The SBI DBCN extension needs to be emulated in user-space
> >
> > Why?
>
> The SBI debug console is similar to a console port available to
> KVM Guest so the KVM user space tool (i.e. QEMU-KVM or
> KVMTOOL) can redirect the input/output of SBI debug console
> wherever it wants (e.g. telnet, file, stdio, etc).
>
> We forward SBI DBCN calls to KVM user space so that the
> in-kernel KVM does not need to be aware of the guest
> console devices.
Hint, my "Why" was attempting to get you to write a better changelog
description, which would include the above information. Please read the
kernel documentation for hints on how to do this so that we know what
why changes are being made.
> > > so let
> > > us forward console_puts() call to user-space.
> >
> > What could go wrong!
> >
> > Why does userspace have to get involved in a console message? Why is
> > this needed at all? The kernel can not handle userspace consoles as
> > obviously they have to be re-entrant and irq safe.
>
> As mentioned above, these are KVM guest console messages which
> the VMM (i.e. KVM user-space) can choose to manage on its own.
If it chooses not to, what happens?
> This is more about providing flexibility to KVM user-space which
> allows it to manage guest console devices.
Why not use the normal virtio console device interface instead of making
a riscv-custom one?
Where is the userspace side of this interface at? Where are the patches
to handle this new api you added?
>
> >
> > >
> > > Signed-off-by: Anup Patel <apatel@ventanamicro.com>
> > > ---
> > > arch/riscv/include/asm/kvm_vcpu_sbi.h | 1 +
> > > arch/riscv/include/uapi/asm/kvm.h | 1 +
> > > arch/riscv/kvm/vcpu_sbi.c | 4 ++++
> > > arch/riscv/kvm/vcpu_sbi_replace.c | 31 +++++++++++++++++++++++++++
> > > 4 files changed, 37 insertions(+)
> > >
> > > diff --git a/arch/riscv/include/asm/kvm_vcpu_sbi.h b/arch/riscv/include/asm/kvm_vcpu_sbi.h
> > > index 8d6d4dce8a5e..a85f95eb6e85 100644
> > > --- a/arch/riscv/include/asm/kvm_vcpu_sbi.h
> > > +++ b/arch/riscv/include/asm/kvm_vcpu_sbi.h
> > > @@ -69,6 +69,7 @@ extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_ipi;
> > > extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_rfence;
> > > extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_srst;
> > > extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_hsm;
> > > +extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_dbcn;
> > > extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_experimental;
> > > extern const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_vendor;
> > >
> > > diff --git a/arch/riscv/include/uapi/asm/kvm.h b/arch/riscv/include/uapi/asm/kvm.h
> > > index 917d8cc2489e..60d3b21dead7 100644
> > > --- a/arch/riscv/include/uapi/asm/kvm.h
> > > +++ b/arch/riscv/include/uapi/asm/kvm.h
> > > @@ -156,6 +156,7 @@ enum KVM_RISCV_SBI_EXT_ID {
> > > KVM_RISCV_SBI_EXT_PMU,
> > > KVM_RISCV_SBI_EXT_EXPERIMENTAL,
> > > KVM_RISCV_SBI_EXT_VENDOR,
> > > + KVM_RISCV_SBI_EXT_DBCN,
> > > KVM_RISCV_SBI_EXT_MAX,
> >
> > You just broke a user/kernel ABI here, why?
>
> The KVM_RISCV_SBI_EXT_MAX only represents the number
> of entries in "enum KVM_RISCV_SBI_EXT_ID" so we are not
> breaking "enum KVM_RISCV_SBI_EXT_ID" rather appending
> new ID to existing enum.
So you are sure that userspace never actually tests or sends that _MAX
value anywhere? If not, why is it even needed?
thanks,
greg k-h
next prev parent reply other threads:[~2023-10-11 7:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 17:04 [PATCH 0/6] RISC-V SBI debug console extension support Anup Patel
2023-10-10 17:04 ` [PATCH 1/6] RISC-V: Add defines for SBI debug console extension Anup Patel
2023-10-10 17:04 ` [PATCH 2/6] RISC-V: KVM: Change the SBI specification version to v2.0 Anup Patel
2023-10-10 17:13 ` Greg Kroah-Hartman
2023-10-11 6:19 ` Anup Patel
2023-10-11 7:27 ` Greg Kroah-Hartman
2023-10-11 11:02 ` Anup Patel
2023-10-11 15:26 ` Greg Kroah-Hartman
2023-10-11 15:38 ` Anup Patel
2023-10-10 17:05 ` [PATCH 3/6] RISC-V: KVM: Forward SBI DBCN extension to user-space Anup Patel
2023-10-10 17:15 ` Greg Kroah-Hartman
2023-10-11 6:32 ` Anup Patel
2023-10-11 7:25 ` Greg Kroah-Hartman [this message]
2023-10-11 10:54 ` Anup Patel
2023-10-10 17:05 ` [PATCH 4/6] tty/serial: Add RISC-V SBI debug console based earlycon Anup Patel
2023-10-10 17:16 ` Greg Kroah-Hartman
2023-10-11 5:52 ` Anup Patel
2023-10-10 17:05 ` [PATCH 5/6] tty: Add SBI debug console support to HVC SBI driver Anup Patel
2023-10-10 17:12 ` Greg Kroah-Hartman
2023-10-11 5:51 ` Anup Patel
2023-10-10 17:05 ` [PATCH 6/6] RISC-V: Enable SBI based earlycon support 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=2023101105-oink-aerospace-989e@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=ajones@ventanamicro.com \
--cc=apatel@ventanamicro.com \
--cc=atishp@atishpatra.org \
--cc=conor@kernel.org \
--cc=jirislaby@kernel.org \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-serial@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=pbonzini@redhat.com \
/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
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).