[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z9MuSsOQuTy1kAwK@google.com>
Date: Thu, 13 Mar 2025 19:13:14 +0000
From: Quentin Perret <qperret@...gle.com>
To: Vincent Donnefort <vdonnefort@...gle.com>
Cc: Marc Zyngier <maz@...nel.org>, Oliver Upton <oliver.upton@...ux.dev>,
Joey Gouly <joey.gouly@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Zenghui Yu <yuzenghui@...wei.com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, linux-arm-kernel@...ts.infradead.org,
kvmarm@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/6] KVM: arm64: Move hyp state to hyp_vmemmap
On Monday 03 Mar 2025 at 09:47:48 (+0000), Vincent Donnefort wrote:
> [...]
>
> > diff --git a/arch/arm64/kvm/hyp/nvhe/setup.c b/arch/arm64/kvm/hyp/nvhe/setup.c
> > index 1a414288fe8c..955c431af5d0 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/setup.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/setup.c
> > @@ -194,16 +194,20 @@ static int fix_host_ownership_walker(const struct kvm_pgtable_visit_ctx *ctx,
> >
> > /*
> > * Adjust the host stage-2 mappings to match the ownership attributes
> > - * configured in the hypervisor stage-1.
> > + * configured in the hypervisor stage-1, and make sure to propagate them
> > + * to the hyp_vmemmap state.
> > */
> > state = pkvm_getstate(kvm_pgtable_hyp_pte_prot(ctx->old));
> > switch (state) {
> > case PKVM_PAGE_OWNED:
> > + set_hyp_state(phys, PKVM_PAGE_OWNED);
> > return host_stage2_set_owner_locked(phys, PAGE_SIZE, PKVM_ID_HYP);
> > case PKVM_PAGE_SHARED_OWNED:
> > + set_hyp_state(phys, PKVM_PAGE_SHARED_OWNED);
> > set_host_state(phys, PKVM_PAGE_SHARED_BORROWED);
> > break;
> > case PKVM_PAGE_SHARED_BORROWED:
> > + set_hyp_state(phys, PKVM_PAGE_SHARED_BORROWED);
> > set_host_state(phys, PKVM_PAGE_SHARED_OWNED);
> > break;
> > default:
>
> Are the SHARED_OWNED/SHARED_BORROWED still relevant since the introduction of
> "KVM: arm64: Don't map 'kvm_vgic_global_state' at EL2 with pKVM"? It doesn't
> seem we have any !OWNED pages in the hyp anymore at setup, do we?
That's a good point. I personally don't hate that we have this code here
for completeness though -- it's simple enough that maintaining it isn't
too bad, and if we were to add shared pages in the future it would 'just
work'. But no strong opinion. I guess we could also remove this code as
a separate clean-up, this isn't specific to this series.
Thanks!
Quentin
Powered by blists - more mailing lists