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 73A63C4332F for ; Mon, 14 Nov 2022 18:21:10 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=723ayC50hS59ktFP3+qDxwDbzU2Md9nkD5puX/GCefo=; b=Xok9f3ubtyTk5W T5uuG5DhStpdpkoMCn9oSjgCC/wBwpqtUWpQ+KoYwr/XE9+BEHgb2akGLBijef6bTK/DRNmx7iNDl r4PlK67nBVrTGy6JeokcQdEAe7VUMq/UuDMvJL9dlyyVz1xxZ6lFc/I8PZ9vBDgi2Z0FDP2iEMxnC zU7fiV+CG8eBJv7DCTHz+TN2nMTanE1PNaC5pwvfTsLFXJPfSNNPrc4qIwGUAXjpxEf7cJBzz+/UJ 5jKbafBkg5YIzM92AuMLS++VsLNM+nID5fuHlAT4ETJPdg5z8IltzRKiBlF7HbhvAE98fLjOV5rCA touUIURoj5mNtXIc2VHQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oue41-003gHU-Gt; Mon, 14 Nov 2022 18:20:09 +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 1oue3y-003gFJ-EC for linux-arm-kernel@lists.infradead.org; Mon, 14 Nov 2022 18:20:08 +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 EB4F16133B; Mon, 14 Nov 2022 18:20:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5655CC4314E; Mon, 14 Nov 2022 18:20:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668450004; bh=CD83SZx2AI5bChI77ue3CZ0IPIH2kxQlAWgz+MlsjTU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YZAnv8ydk7//8upX12rjHE1xKI8Ny5ESoTwjMY3bbKfJeaZtfds1epVNCEqll0pik wP3PFAIVGCbMeK0ldBArv5pXENbjtuzn+yYXqr+XiX2zI5lXLNIi8MGnBV5ySEgkIo IviBQBxvvM2mUSjMVGEtKiWxwFB2HYbI+vnAfSXLvCEb6HNKxgGtzMcQHYbkyGgYgY fT48uv++b/yuNtm+1CmFi+vOTDJOulj716/D3JS7rLn2PWpZyX+MHyeY2iNzjPNxc8 z2J2v3+XoKcGUfYT7cA9u4XEYd2nSKiYtVlsd5/RWpjCWLCfj/4nkCjB9RduzYyjLD 6/4bISUHQJ0zA== Date: Mon, 14 Nov 2022 18:19:57 +0000 From: Will Deacon To: Oliver Upton Cc: Marc Zyngier , kvmarm@lists.linux.dev, Sean Christopherson , Vincent Donnefort , Alexandru Elisei , Catalin Marinas , Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= , James Morse , Chao Peng , Quentin Perret , Suzuki K Poulose , Mark Rutland , Fuad Tabba , kernel-team@android.com, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v6 00/26] KVM: arm64: Introduce pKVM hyp VM and vCPU state at EL2 Message-ID: <20221114181956.GD31476@willie-the-truck> References: <20221110190259.26861-1-will@kernel.org> <86edu9ph3d.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221114_102006_578064_47E092C5 X-CRM114-Status: GOOD ( 38.00 ) 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 Hey Oliver, On Fri, Nov 11, 2022 at 07:42:46PM +0000, Oliver Upton wrote: > On Fri, Nov 11, 2022 at 04:54:14PM +0000, Marc Zyngier wrote: > > On Thu, 10 Nov 2022 19:02:33 +0000, > > Will Deacon wrote: > > > > > > Hi all, > > > > > > This is version six of the pKVM EL2 state series, extending the pKVM > > > hypervisor code so that it can dynamically instantiate and manage VM > > > data structures without the host being able to access them directly. > > > These structures consist of a hyp VM, a set of hyp vCPUs and the stage-2 > > > page-table for the MMU. The pages used to hold the hypervisor structures > > > are returned to the host when the VM is destroyed. > > > > > > Previous versions are archived at: > > > > > > Mega-patch: https://lore.kernel.org/kvmarm/20220519134204.5379-1-will@kernel.org/ > > > v2: https://lore.kernel.org/all/20220630135747.26983-1-will@kernel.org/ > > > v3: https://lore.kernel.org/kvmarm/20220914083500.5118-1-will@kernel.org/ > > > v4: https://lore.kernel.org/kvm/20221017115209.2099-1-will@kernel.org/ > > > v5: https://lore.kernel.org/r/20221020133827.5541-1-will@kernel.org > > > > > > The changes since v5 include: > > > > > > * Fix teardown ordering so that the host 'kvm' structure remains pins > > > while the memcache is being filled. > > > > > > * Fixed a kerneldoc typo. > > > > > > * Included a patch from Oliver to rework the 'pkvm_mem_transition' > > > structure and it's handling of the completer address. > > > > > > * Tweaked some commit messages and added new R-b tags. > > > > > > As before, the final patch is RFC since it illustrates a very naive use > > > of the new hypervisor structures and subsequent changes will improve on > > > this once we have the guest private memory story sorted out. > > > > > > Oliver: I'm pretty sure we're going to need to revert your completer > > > address cleanup as soon as we have guest-host sharing. We want to keep > > > the 'pkvm_mem_transition' structure 'const', but we will only know the > > > host address (PA) after walking the guest stage-2 and so we're going to > > > want to track that separately. Anyway, I've included it here at the end > > > so Marc can decide what he wants to do! > > > > Thanks, I guess... :-/ > > > > If this patch is going to be reverted, I'd rather not take it (without > > guest/host sharing, we don't have much of a hypervisor). > > +1, I'm more than happy being told my patch doesn't work :) > > Having said that, if there are parts of the design that I've whined > about that are intentional then please educate me. Some things haven't > been quite as obvious, but I know you folks have been working on this > feature for a while. Oh sure, I replied on your patches previously: https://lore.kernel.org/r/20221110104215.GA26282@willie-the-truck But here's some more detail... If a guest issues a SHARE hypercall to share a page with the host, then we'll end up in a situation where we have the guest as the initiator and the host as the completer of the share operation. At the point at which we populate the initial (const) 'pkvm_mem_transition' structure, all we will have in our hand is the guest IPA of the page being shared. We can't determine the host (completer) address from this without first walking the guest stage-2 page-table, which happens as part of the guest initiate_share code, so that's why the completer address is decoupled from the rest of the structure -- essentially, it's determine by the initiator after it performs its check. Please do shout if there's something else you're not sure about or if the above is unclear. > I probably need to give the full patch-bomb another read to get all the > context too. We'll probably drop another one of those once 6.2 is out, although we're going to need the guest private memory story to be resolved before we can progress much there, I think. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel