Re: [PATCH v6 00/26] KVM: arm64: Introduce pKVM hyp VM and vCPU state at EL2

From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: "Will Deacon" <will@kernel.org>,
	kvmarm@lists.linux.dev,
	"Vincent Donnefort" <vdonnefort@google.com>,
	"James Morse" <james.morse@arm.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Alexandru Elisei" <alexandru.elisei@arm.com>,
	kernel-team@android.com, "Quentin Perret" <qperret@google.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Suzuki K Poulose" <suzuki.poulose@arm.com>,
	"Fuad Tabba" <tabba@google.com>,
	kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	"Sean Christopherson" <seanjc@google.com>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Chao Peng" <chao.p.peng@linux.intel.com>
Subject: Re: [PATCH v6 00/26] KVM: arm64: Introduce pKVM hyp VM and vCPU state at EL2
Date: Sat, 12 Nov 2022 11:34:09 +0000	[thread overview]
Message-ID: <86bkpcpfta.wl-maz@kernel.org> (raw)
In-Reply-To: <Y26rzvyLQ/1juAAz@google.com>

On Fri, 11 Nov 2022 20:08:46 +0000,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> On Fri, Nov 11, 2022 at 07:06:14PM +0000, Marc Zyngier wrote:
> > On Thu, 10 Nov 2022 19:02:33 +0000, Will Deacon wrote:
> > > 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.
> > > 
> > > [...]
> > 
> > As for Oliver's series, I've tentatively applied this to -next.
> > I've dropped Oliver's patch for now, but kept the RFC one. Maybe I'll
> > change my mind.
> > 
> > Anyway, there was an interesting number of conflicts between the two
> > series, which I tried to resolve as well as I could, but it is likely
> > I broke something (although it compiles, so it must be perfect).
> > 
> > Please have a look and shout if/when you spot something.
> 
> Here is where you and I diverged on the conflict resolution, neither
> amounts to a whole lot but feel free to squash in. Hoping that Will + co
> can test the pKVM side of this.
> 
> diff --git a/arch/arm64/kvm/hyp/nvhe/mm.c b/arch/arm64/kvm/hyp/nvhe/mm.c
> index f2c4672697c2..318298eb3d6b 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mm.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mm.c
> @@ -265,7 +265,7 @@ static int __create_fixmap_slot_cb(const struct kvm_pgtable_visit_ctx *ctx,
>  {
>  	struct hyp_fixmap_slot *slot = per_cpu_ptr(&fixmap_slots, (u64)ctx->arg);
>  
> -	if (!kvm_pte_valid(*ctx->ptep) || ctx->level != KVM_PGTABLE_MAX_LEVELS - 1)
> +	if (!kvm_pte_valid(ctx->old) || ctx->level != KVM_PGTABLE_MAX_LEVELS - 1)
>  		return -EINVAL;
>  
>  	slot->addr = ctx->addr;
> diff --git a/arch/arm64/kvm/hyp/nvhe/setup.c b/arch/arm64/kvm/hyp/nvhe/setup.c
> index b47d969ae4d3..110f04627785 100644
> --- a/arch/arm64/kvm/hyp/nvhe/setup.c
> +++ b/arch/arm64/kvm/hyp/nvhe/setup.c
> @@ -190,7 +190,7 @@ static void hpool_put_page(void *addr)
>  }
>  
>  static int fix_host_ownership_walker(const struct kvm_pgtable_visit_ctx *ctx,
> -					 enum kvm_pgtable_walk_flags visit)
> +				     enum kvm_pgtable_walk_flags visit)
>  {
>  	enum kvm_pgtable_prot prot;
>  	enum pkvm_page_state state;
> 

Thanks. I've folded that in the resolution and regenerated the -next
branch after taking another patch from Gavin in the dirty-ring series.

I've managed to test the result on both VHE and nVHE this morning, and
the wheels are still attached. I don't have a good setup for pKVM at
the moment though, and it is likely that the rest of the monster
series will need some rework.

	M.

-- 
Without deviation from the norm, progress is not possible.