From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 20C0D1A2622 for ; Mon, 26 May 2025 09:22:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748251339; cv=none; b=PLraljEcIMny65UqCREeZOmNwscQZ7Z0R3R+dimJQsk7uh4JUHAFYvPDdpMtjWXBYGFMuKLrf2JVm81MQH2OyeClOHElnWweYS8KvpZP61OKXG6NYPcVAjyHXbbfjUuDmX5NEkPhorx9f914P1HNZqOeIL9MOYqA6IfJ+ysQ7Pg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748251339; c=relaxed/simple; bh=v7yS7OXgu3hum6RTQqAlKfS4MyVozx6fNgU7cA4xzbs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qHrA5FgmG5fIYxykDrLgW9eS8YH3jnQd699Zl37u7uQxFNkx8eQ+Ky3ExrAO0Gen+R29aUA5nxIU7J46OFbWoNPrX2mdlwvEriGmyoRc4YdYA+qR5z2naaFV27pK0dO6SBBclLBR2dKwrKbgRp5CllJel1iiESUD8E0ReDpawm0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com; spf=pass smtp.mailfrom=ventanamicro.com; dkim=pass (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b=Jo2bkt3k; arc=none smtp.client-ip=209.85.221.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ventanamicro.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b="Jo2bkt3k" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-3a3771c0f8cso1441344f8f.3 for ; Mon, 26 May 2025 02:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1748251335; x=1748856135; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=kVB1vMEDILwI7yDAI9DCK169GFiMbj0azQ2wkTKfU94=; b=Jo2bkt3kIR6RlLEsE6p03VMwZsfRdrhbXPO53gOh9ZonWeENh6saDjAXxzWITSODP+ wL8nxlQ3az+aCYAM/wVh888QFHBrHmGHOf1bDNZvlMXHvFA2i0YhLmV8xYNnm9paRyxN S83BfBImElCMUpUApAcu1nLkT2Kc0CFVKEoVUFhP/2ZNoKAp1qXttm0ykYR/Aa8eNTVg jmG0XjloZugo7jlKP3Mdx1sdEvSHd5IChxj/4GleVNHBxuW1dCQaSI/2z+zWa4jqy40C W5rWkJwvHwSoCijMVwhFwN5d1n5gF2f/685S6ggUIaQqnPllVDE5huCZHSfsVI8VBP7M X9ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748251335; x=1748856135; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kVB1vMEDILwI7yDAI9DCK169GFiMbj0azQ2wkTKfU94=; b=wOQ1B+Gfv1Y/bixZaHglEwkO2i5cUFZFtQVXecCRTCl+i6iPCAYINyuc6V15xaAI5k am04+Mxbo81OKvwyqlDA0pwuMr0Kt7k1HUdBCjmTZeGsM3Bzs7P9/xS7tklTGT83BGNM SuyrMUfLupB+z1U1P6nIH1ds/xlXx8x/ddkTjAJ0D0xXcTXFPv82cCm2HrTPYoKfXgT7 ZU+E4DyM0t1LYtKAwoOkSN0qVF7H+nux4r5NnbWwXwQH4WvWigaxR2mPnL2J7co41MCl FJH9obnyaWoqA0DfUEi0prHqTlKiJX/LIvsVLwNekpPuPVYeulfOce5BPBD2Jci4USkU o42A== X-Forwarded-Encrypted: i=1; AJvYcCXZJEkTtNtvgnLMb94uGQWighY6ina82v067Uckkpn7mzwJ15kRJB0osOMkBvqUdjm4wZK7LlM+e54sBcA=@vger.kernel.org X-Gm-Message-State: AOJu0Yx5c2yvhrzLA4H4mQ6WbSkdpmd2BwsNhshZuEJcDdGkd1MhiPMN hmHSH1j5CmR6eZhetO7PjxP/aWpsqRyAKGqikwL+O8ApxFco5N/gXVWFF/BIWFaxXHc= X-Gm-Gg: ASbGncsiuhVfX9jmRvp8jRl2SuKq5YWSZt5WdBHkGbezwHhob66LQ/T17wII/3AMktB oHdYIPC5BkLxuffEy0xc/ouSGucsIfWth3yBs44NlBTLWdD6n+lQ97K8TIn1oBH8YXdvpcUIi5J CfBmOVd0Q7p4y0HS8SgWbiCE2o7EwjbASzC6iigDepGVUQIl/+l1cSz0qdg6AuzQHtYMl3ARnl3 RnGiIYGZee+Oqj+D9qpjKPEXuwGUMPYxpRZEMFZb9hJKR612bFe31tXIwqyZaL5Yq73Xdl/feSX 3bgRz2LPa6Ig7TY75wfJiCcE7LlNqwpDJMvg4iETjLtkU3CaooLo66N/14bqWA/WmAxNFxiMr4r +xdA5 X-Google-Smtp-Source: AGHT+IEGcjh7xBCh+DfeG8xrQT+wvABD+WF/Eu3axSyNQAacMD1k0+ulmhfWAKZW9jVFPAOFjD/p3g== X-Received: by 2002:a05:6000:2407:b0:3a3:6f26:5813 with SMTP id ffacd0b85a97d-3a4cb442ea4mr5934699f8f.25.1748251335337; Mon, 26 May 2025 02:22:15 -0700 (PDT) Received: from localhost (cst2-173-28.cust.vodafone.cz. [31.30.173.28]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4cd0cf5ccsm6703658f8f.8.2025.05.26.02.22.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 May 2025 02:22:14 -0700 (PDT) Date: Mon, 26 May 2025 11:22:14 +0200 From: Andrew Jones To: Radim =?utf-8?B?S3LEjW3DocWZ?= Cc: kvm-riscv@lists.infradead.org, kvm@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Anup Patel , Atish Patra , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti Subject: Re: [PATCH v4] RISC-V: KVM: add KVM_CAP_RISCV_USERSPACE_SBI Message-ID: <20250526-e67c64d52c84a8ad7cb519c4@orel> References: <20250523113347.2898042-3-rkrcmar@ventanamicro.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250523113347.2898042-3-rkrcmar@ventanamicro.com> On Fri, May 23, 2025 at 01:33:49PM +0200, Radim Krčmář wrote: > The new capability allows userspace to implement SBI extensions that KVM > does not handle. This allows userspace to implement any SBI ecall as > userspace already has the ability to disable acceleration of selected > SBI extensions. > The base extension is made controllable as well, but only with the new > capability, because it was previously handled specially for some reason. > *** The related compatibility TODO in the code needs addressing. *** > > This is a VM capability, because userspace will most likely want to have > the same behavior for all VCPUs. We can easily make it both a VCPU and > a VM capability if there is demand in the future. > > Signed-off-by: Radim Krčmář > --- > v4: > * forward base extension as well > * change the id to 242, because 241 is already taken in linux-next > * QEMU example: https://github.com/radimkrcmar/qemu/tree/mp_state_reset > v3: new > --- > Documentation/virt/kvm/api.rst | 11 +++++++++++ > arch/riscv/include/asm/kvm_host.h | 3 +++ > arch/riscv/include/uapi/asm/kvm.h | 1 + > arch/riscv/kvm/vcpu_sbi.c | 17 ++++++++++++++--- > arch/riscv/kvm/vm.c | 5 +++++ > include/uapi/linux/kvm.h | 1 + > 6 files changed, 35 insertions(+), 3 deletions(-) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index e107694fb41f..c9d627d13a5e 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -8507,6 +8507,17 @@ given VM. > When this capability is enabled, KVM resets the VCPU when setting > MP_STATE_INIT_RECEIVED through IOCTL. The original MP_STATE is preserved. > > +7.44 KVM_CAP_RISCV_USERSPACE_SBI > +-------------------------------- > + > +:Architectures: riscv > +:Type: VM > +:Parameters: None > +:Returns: 0 on success, -EINVAL if arg[0] is not zero > + > +When this capability is enabled, KVM forwards ecalls from disabled or unknown > +SBI extensions to userspace. > + > 8. Other capabilities. > ====================== > > diff --git a/arch/riscv/include/asm/kvm_host.h b/arch/riscv/include/asm/kvm_host.h > index 85cfebc32e4c..6f17cd923889 100644 > --- a/arch/riscv/include/asm/kvm_host.h > +++ b/arch/riscv/include/asm/kvm_host.h > @@ -122,6 +122,9 @@ struct kvm_arch { > > /* KVM_CAP_RISCV_MP_STATE_RESET */ > bool mp_state_reset; > + > + /* KVM_CAP_RISCV_USERSPACE_SBI */ > + bool userspace_sbi; > }; > > struct kvm_cpu_trap { > diff --git a/arch/riscv/include/uapi/asm/kvm.h b/arch/riscv/include/uapi/asm/kvm.h > index 5f59fd226cc5..dd3a5dc53d34 100644 > --- a/arch/riscv/include/uapi/asm/kvm.h > +++ b/arch/riscv/include/uapi/asm/kvm.h > @@ -204,6 +204,7 @@ enum KVM_RISCV_SBI_EXT_ID { > KVM_RISCV_SBI_EXT_DBCN, > KVM_RISCV_SBI_EXT_STA, > KVM_RISCV_SBI_EXT_SUSP, > + KVM_RISCV_SBI_EXT_BASE, > KVM_RISCV_SBI_EXT_MAX, > }; > > diff --git a/arch/riscv/kvm/vcpu_sbi.c b/arch/riscv/kvm/vcpu_sbi.c > index 31fd3cc98d66..497d5b023153 100644 > --- a/arch/riscv/kvm/vcpu_sbi.c > +++ b/arch/riscv/kvm/vcpu_sbi.c > @@ -39,7 +39,7 @@ static const struct kvm_riscv_sbi_extension_entry sbi_ext[] = { > .ext_ptr = &vcpu_sbi_ext_v01, > }, > { > - .ext_idx = KVM_RISCV_SBI_EXT_MAX, /* Can't be disabled */ > + .ext_idx = KVM_RISCV_SBI_EXT_BASE, > .ext_ptr = &vcpu_sbi_ext_base, > }, > { > @@ -217,6 +217,11 @@ static int riscv_vcpu_set_sbi_ext_single(struct kvm_vcpu *vcpu, > if (!sext || scontext->ext_status[sext->ext_idx] == KVM_RISCV_SBI_EXT_STATUS_UNAVAILABLE) > return -ENOENT; > > + // TODO: probably remove, the extension originally couldn't be > + // disabled, but it doesn't seem necessary > + if (!vcpu->kvm->arch.userspace_sbi && sext->ext_id == KVM_RISCV_SBI_EXT_BASE) > + return -ENOENT; > + I agree that we don't need to babysit userspace and it's even conceivable to have guests that don't need SBI. KVM should only need checks in its UAPI to protect itself from userspace and to enforce proper use of the API. It's not KVM's place to ensure userspace doesn't violate the SBI spec or create broken guests (userspace is the boss, even if it's a boss that doesn't make sense) So, I vote we drop the check. > scontext->ext_status[sext->ext_idx] = (reg_val) ? > KVM_RISCV_SBI_EXT_STATUS_ENABLED : > KVM_RISCV_SBI_EXT_STATUS_DISABLED; > @@ -471,8 +476,14 @@ int kvm_riscv_vcpu_sbi_ecall(struct kvm_vcpu *vcpu, struct kvm_run *run) > #endif > ret = sbi_ext->handler(vcpu, run, &sbi_ret); > } else { > - /* Return error for unsupported SBI calls */ > - cp->a0 = SBI_ERR_NOT_SUPPORTED; > + if (vcpu->kvm->arch.userspace_sbi) { > + next_sepc = false; > + ret = 0; > + kvm_riscv_vcpu_sbi_forward(vcpu, run); > + } else { > + /* Return error for unsupported SBI calls */ > + cp->a0 = SBI_ERR_NOT_SUPPORTED; > + } > goto ecall_done; > } > > diff --git a/arch/riscv/kvm/vm.c b/arch/riscv/kvm/vm.c > index b27ec8f96697..0b6378b83955 100644 > --- a/arch/riscv/kvm/vm.c > +++ b/arch/riscv/kvm/vm.c > @@ -217,6 +217,11 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, struct kvm_enable_cap *cap) > return -EINVAL; > kvm->arch.mp_state_reset = true; > return 0; > + case KVM_CAP_RISCV_USERSPACE_SBI: > + if (cap->flags) > + return -EINVAL; > + kvm->arch.userspace_sbi = true; > + return 0; > default: > return -EINVAL; > } > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 454b7d4a0448..bf23deb6679e 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -931,6 +931,7 @@ struct kvm_enable_cap { > #define KVM_CAP_X86_GUEST_MODE 238 > #define KVM_CAP_ARM_WRITABLE_IMP_ID_REGS 239 > #define KVM_CAP_RISCV_MP_STATE_RESET 240 > +#define KVM_CAP_RISCV_USERSPACE_SBI 242 > > struct kvm_irq_routing_irqchip { > __u32 irqchip; > -- > 2.49.0 > Otherwise, Reviewed-by: Andrew Jones