lkml.org 
[lkml]   [2021]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH v3 07/15] KVM: arm64: Introduce kvm_share_hyp()
On Thursday 09 Dec 2021 at 11:13:10 (+0000), Will Deacon wrote:
> On Wed, Dec 01, 2021 at 05:04:01PM +0000, Quentin Perret wrote:
> > The create_hyp_mappings() function can currently be called at any point
> > in time. However, its behaviour in protected mode changes widely
> > depending on when it is being called. Prior to KVM init, it is used to
> > create the temporary page-table used to bring-up the hypervisor, and
> > later on it is transparently turned into a 'share' hypercall when the
> > kernel has lost control over the hypervisor stage-1. In order to prepare
> > the ground for also unsharing pages with the hypervisor during guest
> > teardown, introduce a kvm_share_hyp() function to make it clear in which
> > places a share hypercall should be expected, as we will soon need a
> > matching unshare hypercall in all those places.
> >
> > Signed-off-by: Quentin Perret <qperret@google.com>
> > ---
> > arch/arm64/include/asm/kvm_mmu.h | 1 +
> > arch/arm64/kvm/arm.c | 4 ++--
> > arch/arm64/kvm/fpsimd.c | 2 +-
> > arch/arm64/kvm/mmu.c | 27 +++++++++++++++++++++------
> > arch/arm64/kvm/reset.c | 2 +-
> > 5 files changed, 26 insertions(+), 10 deletions(-)
>
> [...]
>
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index f8f1096a297f..fd868fb9d922 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -299,6 +299,25 @@ static int pkvm_share_hyp(phys_addr_t start, phys_addr_t end)
> > return 0;
> > }
> >
> > +int kvm_share_hyp(void *from, void *to)
> > +{
> > + if (is_kernel_in_hyp_mode())
> > + return 0;
> > +
> > + /*
> > + * The share hcall maps things in the 'fixed-offset' region of the hyp
> > + * VA space, so we can only share physically contiguous data-structures
> > + * for now.
> > + */
> > + if (is_vmalloc_addr(from) || is_vmalloc_addr(to))
> > + return -EINVAL;
>
> If we're adding these sanity checks, perhaps is_vmalloc_or_module_addr()
> would be worth using instead?

Ack, I'll fix that up.

\
 
 \ /
  Last update: 2021-12-10 15:37    [W:0.053 / U:0.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site