Message ID | 20231116114152.912344-1-jianyong.wu@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b909:0:b0:403:3b70:6f57 with SMTP id t9csp3150255vqg; Thu, 16 Nov 2023 03:44:58 -0800 (PST) X-Google-Smtp-Source: AGHT+IE+S2A3LJr02a8YiVDd4RnMpOql1iaVTXZxWjLXJW906P1YDiW6BaD1Ohi0gO5lQcQTahat X-Received: by 2002:a17:903:4291:b0:1ca:b26a:9729 with SMTP id ju17-20020a170903429100b001cab26a9729mr8313805plb.38.1700135098468; Thu, 16 Nov 2023 03:44:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700135098; cv=none; d=google.com; s=arc-20160816; b=JFZajn7WC6AfG9ThYI4NqDmcau8t1KHiQWGVVbUul9mLgfT7uiK0dtMVJ8uZPb14i9 mWrxorf1OGWO+1xqm9XE4YzD7thoGpzH7/5AUSbrXMAqGBxzqP3GzgOswzo9zILfpe/T bGrTiPuK3TfsDyWp0pBzNMTmYu6f3YbbZswm4myXqo4aiL2cLkHrvj6ewSZJEuvbP/hM ks6ig9CfyN5jlgBGwzup3Th8UDApyM++erXc3wXIDk8hjtBdVoMZj8DTGFpZvVA6iNpU 3EpoMs0F0Y2KMfXfVznFPIH5t6nR3JG56tEe7gJ5iTE7h0RbQvGsk3yNcP9Kl+H5dbg9 llRg== 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 :message-id:date:subject:cc:to:from; bh=szzttD2WquEdoxao4yGg91DZ18kah2+jK8+sHslBv/g=; fh=Hr0rhk6l8wUYJK5ypP2ZTfcyaXXAb5frA07ghfiGZo8=; b=Uk1jzY9E22E9qbNkDEscK6uEps8oh3qeXl+Nv160BthHdIv4oHVQi7+3iwNpQkQ1Jj XtUbRUwJmYRwyfuQkm8XRJoVAHMXkMxDiwr12vFH4H+85A0AGpCE5Dxa+LkRVl30DUxs EjNw0288+S/wLAbMDiKLoR8IAhwFRLP/6pkTOJ6z+b/GLXLBv8XT7QdSpWv4RMJWS4Bs 8juUw5MvhtsEB+mJdh+dvl3HIrkpxMr1vDMG1LrNuuaSiRaUfgtSHzK/5VW5ePB9pfib FzD9oG+yn3veWTac7KNNLKE2qGVU4AX2BryWhagPVR9n0xQrRJua3xlAoXqgKP1g65tH yIog== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id j14-20020a170903024e00b001c446b59c8dsi12612881plh.271.2023.11.16.03.44.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Nov 2023 03:44:58 -0800 (PST) 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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 4B4C980F696A; Thu, 16 Nov 2023 03:44:56 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345118AbjKPLov (ORCPT <rfc822;jaysivo@gmail.com> + 29 others); Thu, 16 Nov 2023 06:44:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58142 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230160AbjKPLot (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 16 Nov 2023 06:44:49 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 2ECDB182 for <linux-kernel@vger.kernel.org>; Thu, 16 Nov 2023 03:44:45 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B8F1E1595; Thu, 16 Nov 2023 03:45:30 -0800 (PST) Received: from entos-thunderx2-desktop.shanghai.arm.com (entos-thunderx2-desktop.shanghai.arm.com [10.169.214.134]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 2E26B3F6C4; Thu, 16 Nov 2023 03:44:39 -0800 (PST) From: Jianyong Wu <jianyong.wu@arm.com> To: maz@kernel.org, james.morse@arm.com, will@kernel.org Cc: rmk@armlinux.org.uk, salil.mehta@huawei.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, justin.he@arm.com, jianyong.wu@arm.com Subject: [PATCH] arm64/kvm: Introduce feature extension for SMCCC filter Date: Thu, 16 Nov 2023 11:41:52 +0000 Message-Id: <20231116114152.912344-1-jianyong.wu@arm.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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]); Thu, 16 Nov 2023 03:44:56 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782720861238856344 X-GMAIL-MSGID: 1782720861238856344 |
Series |
arm64/kvm: Introduce feature extension for SMCCC filter
|
|
Commit Message
Jianyong Wu
Nov. 16, 2023, 11:41 a.m. UTC
821d935c87b introduces support for userspace SMCCC filtering, but lack
of a way to tell userspace if we have this feature. Add a corresponding
feature extension can resolve this issue.
For example, the incoming feature Vcpu Hotplug needs the SMCCC filter.
As there is no way to check this feature, VMM will run into error when
it calls this feature on an old kernel. It's bad for backward compatible.
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
---
Documentation/virt/kvm/api.rst | 3 ++-
arch/arm64/kvm/arm.c | 1 +
include/uapi/linux/kvm.h | 1 +
3 files changed, 4 insertions(+), 1 deletion(-)
Comments
On Thu, Nov 16 2023, Jianyong Wu <jianyong.wu@arm.com> wrote: > 821d935c87b introduces support for userspace SMCCC filtering, but lack > of a way to tell userspace if we have this feature. Add a corresponding > feature extension can resolve this issue. > > For example, the incoming feature Vcpu Hotplug needs the SMCCC filter. > As there is no way to check this feature, VMM will run into error when > it calls this feature on an old kernel. It's bad for backward compatible. Can't you simply query via KVM_HAS_DEVICE_ATTR whether the SMCCC filtering controls exist? > > Signed-off-by: Jianyong Wu <jianyong.wu@arm.com> > --- > Documentation/virt/kvm/api.rst | 3 ++- > arch/arm64/kvm/arm.c | 1 + > include/uapi/linux/kvm.h | 1 + > 3 files changed, 4 insertions(+), 1 deletion(-) >
> From: Cornelia Huck <cohuck@redhat.com> > Sent: Thursday, November 16, 2023 1:09 PM > To: Jianyong Wu <jianyong.wu@arm.com>; maz@kernel.org; james.morse@arm.com; > will@kernel.org > > On Thu, Nov 16 2023, Jianyong Wu <jianyong.wu@arm.com> wrote: > > > 821d935c87b introduces support for userspace SMCCC filtering, but lack > > of a way to tell userspace if we have this feature. Add a corresponding > > feature extension can resolve this issue. > > > > For example, the incoming feature Vcpu Hotplug needs the SMCCC filter. > > As there is no way to check this feature, VMM will run into error when > > it calls this feature on an old kernel. It's bad for backward compatible. > > Can't you simply query via KVM_HAS_DEVICE_ATTR whether the SMCCC > filtering controls exist? Agreed. In fact, this is what I had earlier intended to do but deferred this change. As of now, RFC V2 of vCPU Hotplug series does not have this check yet while installing the SMCCC filters in KVM Host. Thanks > > Signed-off-by: Jianyong Wu <jianyong.wu@arm.com> > > --- > > Documentation/virt/kvm/api.rst | 3 ++- > > arch/arm64/kvm/arm.c | 1 + > > include/uapi/linux/kvm.h | 1 + > > 3 files changed, 4 insertions(+), 1 deletion(-) > >
On Thu, 16 Nov 2023 13:08:58 +0000, Cornelia Huck <cohuck@redhat.com> wrote: > > On Thu, Nov 16 2023, Jianyong Wu <jianyong.wu@arm.com> wrote: > > > 821d935c87b introduces support for userspace SMCCC filtering, but lack > > of a way to tell userspace if we have this feature. Add a corresponding > > feature extension can resolve this issue. > > > > For example, the incoming feature Vcpu Hotplug needs the SMCCC filter. > > As there is no way to check this feature, VMM will run into error when > > it calls this feature on an old kernel. It's bad for backward compatible. > > Can't you simply query via KVM_HAS_DEVICE_ATTR whether the SMCCC > filtering controls exist? Quite. Commit e0fc6b21616dd introduced it for that exact purpose, specifically to prevent adding more of these capabilities when there is a corresponding attribute that can be readily queried. M.
On Thu, Nov 16, 2023 at 11:41:52AM +0000, Jianyong Wu wrote: > 821d935c87b introduces support for userspace SMCCC filtering, but lack > of a way to tell userspace if we have this feature. Add a corresponding > feature extension can resolve this issue. > > For example, the incoming feature Vcpu Hotplug needs the SMCCC filter. > As there is no way to check this feature, VMM will run into error when > it calls this feature on an old kernel. It's bad for backward compatible. Can't you just attempt to use the SMCCC filtering, and if it errors out with the appropriate error code, decide that SMCCC filtering is not available? That's how most things like kernel syscalls work - if they're not implemented they return -ENOSYS. glibc can detect that and use a fallback. Imagine what it would be like if the kernel provided userspace with a large bitmap of what syscalls were implemented...
On Thu, Nov 16, 2023 at 07:06:18PM +0000, Russell King (Oracle) wrote: > On Thu, Nov 16, 2023 at 11:41:52AM +0000, Jianyong Wu wrote: > > 821d935c87b introduces support for userspace SMCCC filtering, but lack > > of a way to tell userspace if we have this feature. Add a corresponding > > feature extension can resolve this issue. > > > > For example, the incoming feature Vcpu Hotplug needs the SMCCC filter. > > As there is no way to check this feature, VMM will run into error when > > it calls this feature on an old kernel. It's bad for backward compatible. > > Can't you just attempt to use the SMCCC filtering, and if it errors out > with the appropriate error code, decide that SMCCC filtering is not > available? That would also work, as we return ENXIO for the unsupported ioctl. > That's how most things like kernel syscalls work - if they're not > implemented they return -ENOSYS. glibc can detect that and use a > fallback. I generally agree, but KVM has gone in the other direction of providing auxiliary interfaces for discovering new UAPI. ENXIO has been slightly overloaded to imply that a given ioctl is non-existent or otherwise unsupported due to some dynamic configuration. Is it ideal? Of course not. With that said userspace may as well use the preferred / documented discoverability mechanism. And in Jianyong's case the KVM documentation is rather unambiguous (for once) about how you discover device attributes. https://docs.kernel.org/virt/kvm/api.html#kvm-has-device-attr
> -----Original Message----- > From: Salil Mehta <salil.mehta@huawei.com> > Sent: 2023年11月16日 22:06 > To: Cornelia Huck <cohuck@redhat.com>; Jianyong Wu > <Jianyong.Wu@arm.com>; maz@kernel.org; James Morse > <James.Morse@arm.com>; will@kernel.org > Cc: rmk@armlinux.org.uk; Suzuki Poulose <Suzuki.Poulose@arm.com>; > oliver.upton@linux.dev; linux-arm-kernel@lists.infradead.org; > kvmarm@lists.linux.dev; linux-kernel@vger.kernel.org; Justin He > <Justin.He@arm.com>; Jianyong Wu <Jianyong.Wu@arm.com> > Subject: RE: [PATCH] arm64/kvm: Introduce feature extension for SMCCC filter > > > From: Cornelia Huck <cohuck@redhat.com> > > Sent: Thursday, November 16, 2023 1:09 PM > > To: Jianyong Wu <jianyong.wu@arm.com>; maz@kernel.org; > > james.morse@arm.com; will@kernel.org > > > > On Thu, Nov 16 2023, Jianyong Wu <jianyong.wu@arm.com> wrote: > > > > > 821d935c87b introduces support for userspace SMCCC filtering, but > > > lack of a way to tell userspace if we have this feature. Add a > > > corresponding feature extension can resolve this issue. > > > > > > For example, the incoming feature Vcpu Hotplug needs the SMCCC filter. > > > As there is no way to check this feature, VMM will run into error > > > when it calls this feature on an old kernel. It's bad for backward compatible. > > > > Can't you simply query via KVM_HAS_DEVICE_ATTR whether the SMCCC > > filtering controls exist? > > > Agreed. In fact, this is what I had earlier intended to do but deferred this change. > As of now, RFC V2 of vCPU Hotplug series does not have this check yet while > installing the SMCCC filters in KVM Host. > Yes, we can use KVM_HAS_DEVICE_ATTR to do the check in userspace. Thanks Cornelia. Thanks Jianyong > Thanks > > > > Signed-off-by: Jianyong Wu <jianyong.wu@arm.com> > > > --- > > > Documentation/virt/kvm/api.rst | 3 ++- > > > arch/arm64/kvm/arm.c | 1 + > > > include/uapi/linux/kvm.h | 1 + > > > 3 files changed, 4 insertions(+), 1 deletion(-) > > >
> -----Original Message----- > From: Marc Zyngier <maz@kernel.org> > Sent: 2023年11月16日 22:22 > To: Cornelia Huck <cohuck@redhat.com> > Cc: Jianyong Wu <Jianyong.Wu@arm.com>; James Morse > <James.Morse@arm.com>; will@kernel.org; rmk@armlinux.org.uk; > salil.mehta@huawei.com; Suzuki Poulose <Suzuki.Poulose@arm.com>; > oliver.upton@linux.dev; linux-arm-kernel@lists.infradead.org; > kvmarm@lists.linux.dev; linux-kernel@vger.kernel.org; Justin He > <Justin.He@arm.com> > Subject: Re: [PATCH] arm64/kvm: Introduce feature extension for SMCCC filter > > On Thu, 16 Nov 2023 13:08:58 +0000, > Cornelia Huck <cohuck@redhat.com> wrote: > > > > On Thu, Nov 16 2023, Jianyong Wu <jianyong.wu@arm.com> wrote: > > > > > 821d935c87b introduces support for userspace SMCCC filtering, but > > > lack of a way to tell userspace if we have this feature. Add a > > > corresponding feature extension can resolve this issue. > > > > > > For example, the incoming feature Vcpu Hotplug needs the SMCCC filter. > > > As there is no way to check this feature, VMM will run into error > > > when it calls this feature on an old kernel. It's bad for backward compatible. > > > > Can't you simply query via KVM_HAS_DEVICE_ATTR whether the SMCCC > > filtering controls exist? > > Quite. Commit e0fc6b21616dd introduced it for that exact purpose, specifically > to prevent adding more of these capabilities when there is a corresponding > attribute that can be readily queried. Exactly. Commit e0fc6b21616dd has done for this. Ignore this patch. Thanks Jianyong > > M. > > -- > Without deviation from the norm, progress is not possible.
> From: Oliver Upton <oliver.upton@linux.dev> > Sent: Thursday, November 16, 2023 11:22 PM > To: Russell King (Oracle) <linux@armlinux.org.uk> > > On Thu, Nov 16, 2023 at 07:06:18PM +0000, Russell King (Oracle) wrote: > > On Thu, Nov 16, 2023 at 11:41:52AM +0000, Jianyong Wu wrote: > > > 821d935c87b introduces support for userspace SMCCC filtering, but lack > > > of a way to tell userspace if we have this feature. Add a corresponding > > > feature extension can resolve this issue. > > > > > > For example, the incoming feature Vcpu Hotplug needs the SMCCC filter. > > > As there is no way to check this feature, VMM will run into error when > > > it calls this feature on an old kernel. It's bad for backward compatible. > > > > Can't you just attempt to use the SMCCC filtering, and if it errors out > > with the appropriate error code, decide that SMCCC filtering is not > > available? > > That would also work, as we return ENXIO for the unsupported ioctl. > > > That's how most things like kernel syscalls work - if they're not > > implemented they return -ENOSYS. glibc can detect that and use a > > fallback. > > I generally agree, but KVM has gone in the other direction of providing > auxiliary interfaces for discovering new UAPI. ENXIO has been slightly > overloaded to imply that a given ioctl is non-existent or otherwise > unsupported due to some dynamic configuration. Agreed. We require this check for vCPU Hotplug series as well exactly for the reason you stated above i.e. to clearly distinguish the case when KVM host does not support SMCCC filter and when it does but an error is purged out during configuration of this filter. In the later we would like to abort the VM initialization (as being done in RFC V2) but in former we would just continue without supporting vCPU Hotplug feature. Handling is different in each. Thanks Salil. > > Is it ideal? Of course not. With that said userspace may as well use the > preferred / documented discoverability mechanism. And in Jianyong's case > the KVM documentation is rather unambiguous (for once) about how you > discover device attributes. > > https://docs.kernel.org/virt/kvm/api.html#kvm-has-device-attr > > -- > Thanks, > Oliver
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 7025b3751027..559c6c531bfd 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6395,7 +6395,8 @@ For arm64: ---------- SMCCC exits can be enabled depending on the configuration of the SMCCC -filter. See the Documentation/virt/kvm/devices/vm.rst +filter. This feature can be only available if KVM_CAP_ARM_VM_SMCCC is +upported. See the Documentation/virt/kvm/devices/vm.rst ``KVM_ARM_SMCCC_FILTER`` for more details. ``nr`` contains the function ID of the guest's SMCCC call. Userspace is diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index e5f75f1f1085..44583da440ae 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -241,6 +241,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) case KVM_CAP_ARM_SYSTEM_SUSPEND: case KVM_CAP_IRQFD_RESAMPLE: case KVM_CAP_COUNTER_OFFSET: + case KVM_CAP_ARM_VM_SMCCC: r = 1; break; case KVM_CAP_SET_GUEST_DEBUG2: diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 211b86de35ac..e67fb1df508d 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -1201,6 +1201,7 @@ struct kvm_ppc_resize_hpt { #define KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE 228 #define KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES 229 #define KVM_CAP_ARM_SUPPORTED_REG_MASK_RANGES 230 +#define KVM_CAP_ARM_VM_SMCCC 231 #ifdef KVM_CAP_IRQ_ROUTING