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 E1099C433FE for ; Mon, 14 Nov 2022 11:38:34 +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:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=kkw2jFUd82buPlVBJOJ+HV1ssWdX2qwlyuu2yGKHYTI=; b=ho36I6gNVo1Qhw xmWX+VrlqOnNj9sC6bnJgrbKjia/a1vDDB9TeqT/YfD9LsUzMEqr39suvOHX7BJU/Ck0aejM8nO7y l5LAAv3jU4SfkXxTj5ZpKMppURcPTKipLWu7IDAkrw8mY13zUMhTSNIzWbSBOwXTNyJqHWdTduYUh TIs/kCIh0knnY6ikpMCZQpdGfdIJL36QyiO7vUmvI9QRXvPFsGynVjw35UbW9uiBCyDgcdSELrLVu 8UOPRmJSmhOYA38B3xvqlnW4xZuqYLpd+AirvEulnnYX9U6fmn3Z+kyKjikdIRjU+j1ZytRPNprYo SLOLTtH+rnSFwzQW5v3g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ouXmM-000RFN-1Q; Mon, 14 Nov 2022 11:37:30 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ouXmI-000RDo-RM for linux-arm-kernel@lists.infradead.org; Mon, 14 Nov 2022 11:37:28 +0000 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 dfw.source.kernel.org (Postfix) with ESMTPS id F2B6C61046; Mon, 14 Nov 2022 11:37:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5718EC433C1; Mon, 14 Nov 2022 11:37:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668425845; bh=X1WXUuEiCKYnCaSnllroe9lO9yo1oclX61iorR2hfP8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=W8W7cT4G0eRhxxQtb/fG1Agad036i8WDiWbKv+7fyVCRbtdWrMK0YRAUyw3aA0cHv ZixjCxb6xkWxqH5vTFUokG6TPXIq7Ol4JOU4fSPj46hFKxF9o6LqvVYGAf/qIj0dRx fzjrxfpBWMiGe9oed60NTUh8lNzyzzztJ24pcs+XFTQKWOSURKyt2/4vkP2VMwB4hU 2AXgwCfpB9N9TCctCLljVhTZhCWNhexgwkpNsr3ukcvsbqh3zrRDfkPWGGY5+s3sqc uNh4JUM9cFMn4VTneWbR/GZGzDkGHZVvYV/vwdjfN4/ZrdQ+0qVyexESqBNmYgvaoh sm39gLiANN6CA== Received: from [82.3.55.76] (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 1ouXmE-005wky-Vy; Mon, 14 Nov 2022 11:37:23 +0000 Date: Mon, 14 Nov 2022 11:36:56 +0000 Message-ID: <878rkdvkbr.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: James Morse , Alexandru Elisei , Suzuki K Poulose , Catalin Marinas , Will Deacon , Paolo Bonzini , Raghavendra Rao Ananta , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [RFC PATCH 2/3] KVM: arm64: Allow userspace to trap SMCCC sub-ranges In-Reply-To: References: <20221110015327.3389351-1-oliver.upton@linux.dev> <20221110015327.3389351-3-oliver.upton@linux.dev> <86o7tfov7v.wl-maz@kernel.org> <87fsepvqw5.wl-maz@kernel.org> 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") X-SA-Exim-Connect-IP: 82.3.55.76 X-SA-Exim-Rcpt-To: oliver.upton@linux.dev, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, pbonzini@redhat.com, rananta@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, kvm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221114_033726_986306_BD4F7857 X-CRM114-Status: GOOD ( 39.16 ) 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 On Fri, 11 Nov 2022 23:39:09 +0000, Oliver Upton wrote: > > On Fri, Nov 11, 2022 at 08:26:02AM +0000, Marc Zyngier wrote: > > On Thu, 10 Nov 2022 21:13:54 +0000, Oliver Upton wrote: > > > The goal of what I was trying to get at is that either the kernel or > > > userspace takes ownership of a range that has an ABI, but not both. i.e. > > > you really wouldn't want some VMM or cloud provider trapping portions of > > > KVM's vendor-specific range while still reporting a 'vanilla' ABI at the > > > time of discovery. Same goes for PSCI, TRNG, etc. > > > > But I definitely think this is one of the major use cases. For > > example, there is value in taking PSCI to userspace in order to > > implement a newer version of the spec, or to support sub-features that > > KVM doesn't (want to) implement. I don't think this changes the ABI from > > the guest perspective. > > I disagree for the implications of partially trapping the 'Vendor > Specific Hypervisor Service'. If the UID for the range still reports KVM > but userspace decided to add some new widget, then from the guest > perspective that widget is now part of KVM's own ABI with the guest. But that's what I mean by "I don't think this changes the ABI from the guest perspective". The guest cannot know who is doing the emulation anyway, so it is userspace's duty to preserve the illusion. At the end of the day, this is only a configuration mechanism, and it is no different from all other configuration bits (i.e. they need to be identical on both side for migration). > Trapping the whole range is a bit of a hack to workaround the need for > more complicated verification of a hypercall filter. We already need these things for architected hypercalls. Once we have the infrastructure, it doesn't matter anymore which range this is for. > > But for everything else, I'm fine with arbitrary function filtering. > Userspace is always welcome to shoot itself in the foot. > > > pKVM also has a use case for this where userspace gets a notification > > of the hypercall that a guest has performed to share memory. > > Is that hypercall in the 'Vendor Specific Hypervisor Service' range? Yes. It is get another KVM hypercall. > > > Communication with a TEE also is on the cards, as would be a FFA > > implementation. All of this could be implemented in KVM, or in > > userspace, depending what users of these misfeatures want to do. > > I'm very hopeful that by forwarding all of this to userspace we can get > out of the business of implementing every darn spec that comes along. Good luck. All the TEEs have private, home grown APIs, and every vendor will want to implement their own crap (i.e. there is no spec). M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel