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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CAD36C636D3 for ; Wed, 8 Feb 2023 09:02:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230325AbjBHJCV (ORCPT ); Wed, 8 Feb 2023 04:02:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49982 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229598AbjBHJCR (ORCPT ); Wed, 8 Feb 2023 04:02:17 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3084915568; Wed, 8 Feb 2023 01:02:16 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id CFF1EB81C6A; Wed, 8 Feb 2023 09:02:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 778D4C433A0; Wed, 8 Feb 2023 09:02:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675846933; bh=Au9MWvR8WSilVR5o+G1SBG0j1tkJGbQ1BYt+vNhmIjE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RzQiZ9P6NDDC6vH0trcQ+X2uILhWWJkrt7w+rg5sjO3axMWd9ufymHHtAWCV7eUqM fjAVNVi0+LTcNRR/9g4MpfdnptHZaX9SFbjlPF7S/NDq6hsgVkqHzcWmVNnqaNzrMD MSkofGRklN9fhQfkxl7z7jeZmJqtZRcSCZjdWnHZzr3MpC+TtmwHuRNNS8tDu6i7yz D0ShsgTgsIGKOHCWr2jWrCUf8c6PPX6NLy/tGbT6kWGgYUWy8gDNUwjdBdslnJe24f hj2PWLvbvaqv/tKaepwKx9+ywYeFCX/gY1aRb3iikq4ryc4DBq8BCLhh/NFh6gIMQ3 z2Qv8NH9XA0Nw== Received: from [104.132.45.110] (helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pPgLD-008bNL-4P; Wed, 08 Feb 2023 09:02:11 +0000 Date: Wed, 08 Feb 2023 09:02:09 +0000 Message-ID: <877cws1qem.wl-maz@kernel.org> From: Marc Zyngier To: James Morse Cc: Oliver Upton , linux-pm@vger.kernel.org, loongarch@lists.linux.dev, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arch@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, Thomas Gleixner , Lorenzo Pieralisi , Mark Rutland , Sudeep Holla , Borislav Petkov , H Peter Anvin , Dave Hansen , Ingo Molnar , Will Deacon , Catalin Marinas , Huacai Chen , Suzuki K Poulose , Len Brown , Rafael Wysocki , WANG Xuerui , Salil Mehta , Russell King , Jean-Philippe Brucker Subject: Re: [RFC PATCH 29/32] KVM: arm64: Pass hypercalls to userspace In-Reply-To: <0621bf8e-06f2-70f2-6d2b-f311c5a4ffce@arm.com> References: <20230203135043.409192-1-james.morse@arm.com> <20230203135043.409192-30-james.morse@arm.com> <0621bf8e-06f2-70f2-6d2b-f311c5a4ffce@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 104.132.45.110 X-SA-Exim-Rcpt-To: james.morse@arm.com, oliver.upton@linux.dev, linux-pm@vger.kernel.org, loongarch@lists.linux.dev, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arch@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, tglx@linutronix.de, lpieralisi@kernel.org, mark.rutland@arm.com, sudeep.holla@arm.com, bp@alien8.de, hpa@zytor.com, dave.hansen@linux.intel.com, mingo@redhat.com, will@kernel.org, catalin.marinas@arm.com, chenhuacai@kernel.org, suzuki.poulose@arm.com, lenb@kernel.org, rafael@kernel.org, kernel@xen0n.name, salil.mehta@huawei.com, linux@armlinux.org.uk, jean-philippe@linaro.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 07 Feb 2023 17:50:59 +0000, James Morse wrote: > > Hi Oliver, > > On 03/02/2023 21:08, Oliver Upton wrote: > > On Fri, Feb 03, 2023 at 01:50:40PM +0000, James Morse wrote: > >> From: Jean-Philippe Brucker > >> > >> When capability KVM_CAP_ARM_HVC_TO_USER is available, userspace can > >> request to handle all hypercalls that aren't handled by KVM. > > > I would very much prefer we not go down this route. This capability > > effectively constructs an ABI out of what KVM presently does not > > implement. What would happen if KVM decides to implement a new set > > of hypercalls later down the road that were previously forwarded to > > userspace? > > The user-space support would never get called. If we have a > wild-west allocation of IDs in this area we have bigger > problems. I'd hope in this example it would be a VMM or an in-kernel > implementation of the same feature. > > When I floated something like this before for supporting SDEI in > guests, Christoffer didn't like tie-ing KVM to SMC-CC - hence the > all or nothing. > > Since then we've had things like Spectre, which I don't think the > VMM should ever be allowed to handle, which makes the whole thing > much murkier. That ship has sailed a long time ago. We also have grown a bunch of in-kernel SMCCC services that are KVM specific (the silly PTP stuff, for example, not to mention all the pKVM hypercalls...). It is also likely that these ranges will grow over time (it has been a long time since the last drop of Spectre-like crap, and something must be brewing somewhere), so a level of discrimination is important. M. -- Without deviation from the norm, progress is not possible.