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

[Will Deacon <will@kernel.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 <will@kernel.org> 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