From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CF736C54FB9 for ; Tue, 21 Nov 2023 10:58:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=YWExA+tqw44VncJKO/RJi50XAx9qVG1SxCJPRcRON/w=; b=yer2vtq0ucYfCP uRCZv4MU/nT2eV25iLn85cT0MPMCmZ1aJ2bPu3ezBdIQJL95K4/qCBNR8If0lp2VygKGzPTdmSJJg YRUIwJqD/7mNubl38J5txYLk9mzBHiCICV2Roi1UKQeuYkiSSIlYwfJDI3u0s1ZCY76Xa//PQ3Uex MHfymm6/8YKr1WjUG0mnJNIiPvgN2NmeV+ZW1ZoDiNmy07MGUkUKgPcSArqdOTKkLMzrNjw3sNq71 FgmqPRiIjtDt34N0QshcrPhfBtrqjcGDgMXJCBCcBb1XzgsGvj2zZkgmKlFvhVkL/fQDhMweWza+1 J9Qq/1kwFHgykAWv0jQw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r5ORx-00GKnU-1y; Tue, 21 Nov 2023 10:57:49 +0000 Received: from frasgout.his.huawei.com ([185.176.79.56]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r5ORt-00GKkp-0A for linux-arm-kernel@lists.infradead.org; Tue, 21 Nov 2023 10:57:47 +0000 Received: from lhrpeml100001.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4SZLmv0DcRz6J9yP; Tue, 21 Nov 2023 18:52:31 +0800 (CST) Received: from lhrpeml500001.china.huawei.com (7.191.163.213) by lhrpeml100001.china.huawei.com (7.191.160.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 21 Nov 2023 10:57:27 +0000 Received: from lhrpeml500001.china.huawei.com ([7.191.163.213]) by lhrpeml500001.china.huawei.com ([7.191.163.213]) with mapi id 15.01.2507.035; Tue, 21 Nov 2023 10:57:27 +0000 From: Salil Mehta To: Oliver Upton , "Russell King (Oracle)" CC: Jianyong Wu , "maz@kernel.org" , "james.morse@arm.com" , "will@kernel.org" , "suzuki.poulose@arm.com" , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "justin.he@arm.com" Subject: RE: [PATCH] arm64/kvm: Introduce feature extension for SMCCC filter Thread-Topic: [PATCH] arm64/kvm: Introduce feature extension for SMCCC filter Thread-Index: AQHaGIJSPxqmEiVqkkOrXIqhoEeoZ7B9TvAAgABHfQCABwlmkA== Date: Tue, 21 Nov 2023 10:57:27 +0000 Message-ID: <9367235ee3b34a30af43a5689173f61e@huawei.com> References: <20231116114152.912344-1-jianyong.wu@arm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.195.245.211] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231121_025745_394079_4EDF9DB7 X-CRM114-Status: GOOD ( 25.49 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org > From: Oliver Upton > Sent: Thursday, November 16, 2023 11:22 PM > To: Russell King (Oracle) > > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel