Message ID | 20231010170503.657189-4-apatel@ventanamicro.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp7672vqb; Tue, 10 Oct 2023 10:05:56 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEBSFAHOed6UgbD9Qxqr7Q0dSYgwXSdHjganLaHIDQOwRLs+xb7t/Lrb7tRvOC4dGCQYthz X-Received: by 2002:a17:903:2305:b0:1c6:c3f:9dc3 with SMTP id d5-20020a170903230500b001c60c3f9dc3mr17233478plh.54.1696957556452; Tue, 10 Oct 2023 10:05:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696957556; cv=none; d=google.com; s=arc-20160816; b=zTycT+xrO3yirDLmaIQWQy830ONyOLzxRWPrk3/h12Sg0sxkA1U/Wj9/VARDPMubMu rE7cgfocjiW8OILumqW7nWrv5Q+PeKgDmnlAWe88pECAA4d9Xbgjq4geEqe14JGFi+9R xtV6WFtp552zgxxAf5WxlT5bQnQq1+rAIyDUC2z2M423Ev2rDd/fg2zu8GFrveZ30DPz KDSyxq3deSZOaClLAeyqZItDkIzi+GBatHt/ugQkQ6yzcy1g/uFFQSQDvI0uklWCvXeo J7dZ6AfaGDjqI8Oeswj9NYLA4Yp6azyrip+1fJmxq6KpjPR/hqtpR1A+G5bqZlKXzKWe 8znQ== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=4smwE6VqfYxKvfF0tqu7jNc/7OXpVUXHc/+OAD0MBRk=; fh=7GYORjoWw1oF4BCDuq40hd+MOEKRwzNqXwnZ/K2vS9Q=; b=jLdg87Mi0d9RQA8eHb3eQKaxPUHhPQZit5jCmvDwFLDLhxaHvlaKPu5tG5AEvtoN3S FBSV1/fwDXHNyKUSeUSyK/FbhA1RHZv97jpDUJkdZy70mHDvjMRFdUauAi3L/qer9bJL 1PO1Z48BSa4FdofV/t2xOFNLJlhr5QbC6WGULgYHG9WorljmLKXkGy+diE+bU+Bc3ZOE wr+tJORZ7kK2ukcQpD2k//sED/xHLmRtpHBzR138g4w5uF7S30WqO1RpsORi3M+1xNsy Cl6uMKgYHv8gtMnUJWqoO8LhBdUTR8eDWn46EukbsjUeYnETpy/56yRlh3rUeWMf3Lq4 +e1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ventanamicro.com header.s=google header.b=FhwWGb5X; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id d2-20020a170902cec200b001c61226fe40si13147537plg.392.2023.10.10.10.05.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Oct 2023 10:05:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=pass header.i=@ventanamicro.com header.s=google header.b=FhwWGb5X; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 830568044776; Tue, 10 Oct 2023 10:05:53 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234044AbjJJRFi (ORCPT <rfc822;rua109.linux@gmail.com> + 20 others); Tue, 10 Oct 2023 13:05:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53828 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233978AbjJJRFd (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 10 Oct 2023 13:05:33 -0400 Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D14638E for <linux-kernel@vger.kernel.org>; Tue, 10 Oct 2023 10:05:30 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-1c9bf22fe05so5061575ad.2 for <linux-kernel@vger.kernel.org>; Tue, 10 Oct 2023 10:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1696957530; x=1697562330; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=4smwE6VqfYxKvfF0tqu7jNc/7OXpVUXHc/+OAD0MBRk=; b=FhwWGb5Xse7nvJyYxyIZeHfhdiov1sPmpAIyzOeoCGEf39LOxkt7wfJ2Z0P8A/m678 rZFtelP2j0l+cFV4L9Fd5cfVSWv91bpzgvCS53XnUBi1zh9W1Xz36U8+NoWS9joAjSbI PIzEhCDhs/CTR2GXh1mg5mra4y83r13ciVymQInsYDZrGiCQZaGGVuYTeY9T7kjMtIJK aeud+i6Sr7MfTROpnE4KzDCOMsNYMbUUKOD2aJVn1Xog8btOol7bejKOotidRPs3u8N9 cT7AmZcOJCLaEJ70+JIuVaq/Iqpb+vIlh89lPryRr+V5veLBho8HplAufaN1fMW6m+Ks 6RwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696957530; x=1697562330; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4smwE6VqfYxKvfF0tqu7jNc/7OXpVUXHc/+OAD0MBRk=; b=rb4pnaGoL0sXjsxvP0Hw6SOJU/N/137Pv2g3OrjfHQYI3I31UrCOY5Lif/8oE+ui+q wdm/7IalD4p5Qsvitwtu9ct95QQdbbABdFVfXUMzlUj1nMY+BFLTKIi8epRwwQHUuIC0 8VTdMB4pNmOWqc79QxRAekI5K8ZtDSSCLqiNPF6+Pf4nKLgufKXwu0J/MsseZI/f4QmR wlXCrH0OD8VVH6ybk/ERlp97wIBuBOyhBW43B3poLguRSeF1timjqq/U8i+pcaIhF5XH gw1OCH2WuQzJrVpneqe6T4Nlq6zwa5niCQoKqwZAKIV29+lOks9X+NP6UPSlRWzzg0Eb mpPw== X-Gm-Message-State: AOJu0YwfL1iqKXaslnlcJ0Y8bxagtnT8FbLnfY4Y2thgmsBW4HX3way4 eFHA9Lh8AIgMn4hVQFr3TeANpg== X-Received: by 2002:a17:902:a402:b0:1c7:7e00:809e with SMTP id p2-20020a170902a40200b001c77e00809emr15730697plq.67.1696957529924; Tue, 10 Oct 2023 10:05:29 -0700 (PDT) Received: from anup-ubuntu-vm.localdomain ([103.97.165.210]) by smtp.gmail.com with ESMTPSA id w19-20020a1709027b9300b001b89536974bsm11979868pll.202.2023.10.10.10.05.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Oct 2023 10:05:29 -0700 (PDT) From: Anup Patel <apatel@ventanamicro.com> To: Paolo Bonzini <pbonzini@redhat.com>, Atish Patra <atishp@atishpatra.org>, Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Jiri Slaby <jirislaby@kernel.org> Cc: 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, Anup Patel <apatel@ventanamicro.com> Subject: [PATCH 3/6] RISC-V: KVM: Forward SBI DBCN extension to user-space Date: Tue, 10 Oct 2023 22:35:00 +0530 Message-Id: <20231010170503.657189-4-apatel@ventanamicro.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231010170503.657189-1-apatel@ventanamicro.com> References: <20231010170503.657189-1-apatel@ventanamicro.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Tue, 10 Oct 2023 10:05:53 -0700 (PDT) X-Spam-Level: ** X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779388966803118032 X-GMAIL-MSGID: 1779388966803118032 |
Series |
RISC-V SBI debug console extension support
|
|
Commit Message
Anup Patel
Oct. 10, 2023, 5:05 p.m. UTC
The SBI DBCN extension needs to be emulated in user-space so let
us forward console_puts() call to user-space.
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(+)
Comments
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? > 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. > > 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? thanks, greg k-h
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. > > > 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. This is more about providing flexibility to KVM user-space which allows it to manage guest console devices. > > > > > 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. > > thanks, > > greg k-h Thanks, Anup
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
On Wed, Oct 11, 2023 at 12:56 PM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > 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. Okay, I will improve the commit description and cover-letter. > > > > > 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? If KVM user-space chooses not to handle SBI DBCN calls then it can disable SBI DBCN extension for Guest VCPUs using the ONE_REG ioctl() interface. > > > 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? The SBI DBCN (or debug console) is only an early console used for early prints and bootloaders. Once the proper console (like virtio console) is detected by the Guest kernel, it will switch the debug console to proper console. > > Where is the userspace side of this interface at? Where are the patches > to handle this new api you added? As mentioned in the cover letter, I have implemented it in KVMTOOL first. The patches can be found in riscv_sbi_dbcn_v1 branch at: https://github.com/avpatel/kvmtool.git More precisely, this commit: https://github.com/avpatel/kvmtool/commit/06a373ee8991f882ef79de3845a4c8d63cb189a6 > > > > > > > > > > > > > > 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 Regards, Anup
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, }; diff --git a/arch/riscv/kvm/vcpu_sbi.c b/arch/riscv/kvm/vcpu_sbi.c index 9cd97091c723..b54fe52c915a 100644 --- a/arch/riscv/kvm/vcpu_sbi.c +++ b/arch/riscv/kvm/vcpu_sbi.c @@ -66,6 +66,10 @@ static const struct kvm_riscv_sbi_extension_entry sbi_ext[] = { .ext_idx = KVM_RISCV_SBI_EXT_PMU, .ext_ptr = &vcpu_sbi_ext_pmu, }, + { + .ext_idx = KVM_RISCV_SBI_EXT_DBCN, + .ext_ptr = &vcpu_sbi_ext_dbcn, + }, { .ext_idx = KVM_RISCV_SBI_EXT_EXPERIMENTAL, .ext_ptr = &vcpu_sbi_ext_experimental, diff --git a/arch/riscv/kvm/vcpu_sbi_replace.c b/arch/riscv/kvm/vcpu_sbi_replace.c index 7c4d5d38a339..347c5856347e 100644 --- a/arch/riscv/kvm/vcpu_sbi_replace.c +++ b/arch/riscv/kvm/vcpu_sbi_replace.c @@ -175,3 +175,34 @@ const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_srst = { .extid_end = SBI_EXT_SRST, .handler = kvm_sbi_ext_srst_handler, }; + +static int kvm_sbi_ext_dbcn_handler(struct kvm_vcpu *vcpu, + struct kvm_run *run, + struct kvm_vcpu_sbi_return *retdata) +{ + struct kvm_cpu_context *cp = &vcpu->arch.guest_context; + unsigned long funcid = cp->a6; + + switch (funcid) { + case SBI_EXT_DBCN_CONSOLE_WRITE: + case SBI_EXT_DBCN_CONSOLE_READ: + case SBI_EXT_DBCN_CONSOLE_WRITE_BYTE: + /* + * The SBI debug console functions are unconditionally + * forwarded to the userspace. + */ + kvm_riscv_vcpu_sbi_forward(vcpu, run); + retdata->uexit = true; + break; + default: + retdata->err_val = SBI_ERR_NOT_SUPPORTED; + } + + return 0; +} + +const struct kvm_vcpu_sbi_extension vcpu_sbi_ext_dbcn = { + .extid_start = SBI_EXT_DBCN, + .extid_end = SBI_EXT_DBCN, + .handler = kvm_sbi_ext_dbcn_handler, +};