From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out2.migadu.com (out2.migadu.com [188.165.223.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EDA93368 for ; Fri, 11 Nov 2022 19:42:59 +0000 (UTC) Date: Fri, 11 Nov 2022 19:42:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1668195771; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=489V1xO2Jk4quKvIvlMb+9p2vWfkmCHH5cQqMf67ius=; b=ctsL1hsC7qEw5KiW28UAtXJRlnFS4iPL22CHt0GFvCmPRUlo8Rsweb1Y6WREvqho0r9sXc N657AWKzK8lHkXEclZcbTk1apEVn4VSgW4n9PysclSm15DxsXi37Yd1oYbNU8SA3MqXrE4 7J/tg6Q6syps7GjxLcmOHG3ltCVunSU= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Marc Zyngier Cc: Will Deacon , 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: References: <20221110190259.26861-1-will@kernel.org> <86edu9ph3d.wl-maz@kernel.org> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86edu9ph3d.wl-maz@kernel.org> X-Migadu-Flow: FLOW_OUT 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. I probably need to give the full patch-bomb another read to get all the context too. -- Thanks, Oliver 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 DEE2FC4332F for ; Fri, 11 Nov 2022 19:44:09 +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=Hi0AiP/2yOV8a0XjZ3YyIwLwLedKqKtb+A+HAFD4gPY=; b=Lejn+gJ9Jejgq9 xjTJI2QK1TS2Qetf9G8F0tjID+AvvnaGxlhMyxDpzWaWqnEQsd6r3lTlJ80zagCwwtfw1XyByVhcx DykhKr4SsNA88kGdTf/YtvNYgvVWEIPRXJ144d7AouUvEL0VDpifeRDkJJaos+n66C5fXZiMzC2/h udFvv+UkncCUKsFCR8XyhhZrto2HgTW1m4i1fWZPl2Yjml3mczzwD/aazQ+b/3g4q7tWzKEXjjacg Ygf/8VubqI9FByNfr8vU8XHQzAdvHQHeJz6jTgR5Q5y0+Mps+0w4qi0KW4+Eru1PuvsP+H9ExbPCW bSJW9SLKQGt4GzavBLEQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1otZvg-000fa8-Po; Fri, 11 Nov 2022 19:43:08 +0000 Received: from out2.migadu.com ([2001:41d0:2:aacc::]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1otZvZ-000fTr-0T for linux-arm-kernel@lists.infradead.org; Fri, 11 Nov 2022 19:43:06 +0000 Date: Fri, 11 Nov 2022 19:42:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1668195771; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=489V1xO2Jk4quKvIvlMb+9p2vWfkmCHH5cQqMf67ius=; b=ctsL1hsC7qEw5KiW28UAtXJRlnFS4iPL22CHt0GFvCmPRUlo8Rsweb1Y6WREvqho0r9sXc N657AWKzK8lHkXEclZcbTk1apEVn4VSgW4n9PysclSm15DxsXi37Yd1oYbNU8SA3MqXrE4 7J/tg6Q6syps7GjxLcmOHG3ltCVunSU= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Marc Zyngier Cc: Will Deacon , 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: References: <20221110190259.26861-1-will@kernel.org> <86edu9ph3d.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <86edu9ph3d.wl-maz@kernel.org> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221111_114301_217783_A87CBE1F X-CRM114-Status: GOOD ( 30.22 ) 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, 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. I probably need to give the full patch-bomb another read to get all the context too. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel